Home
Documentation
This Help Center provides documentation on all aspects of the HCL Commerce+ product, from installation and deployment to operating and customization.
Securing
These topics describe the security features of Commerce+ and how to configure these features.
Site security considerations
To enhance the security of your Commerce+ site, you can enable various features in Administration Console or in the Commerce+ configuration file.
Transport Layer Security (TLS) protocol Version 1.3
Use the latest TLS security protocol to protect your site. This prevents attackers from exploiting weaknesses in older, less secure versions to steal sensitive data.

Documentation
This Help Center provides documentation on all aspects of the HCL Commerce+ product, from installation and deployment to operating and customization.
- Overview
  Welcome to the HCL Commerce+ overview. Explore these feature overviews to learn how Commerce+ operates. Refer to the related links listed at the end of each topic to access expanded product documentation.
- Deploying
  This section provides details on deploying HCL Commerce+. It explains how to download the Docker images and Git bundles that comprise the product, how to create a minimal environment, and how to plan for a full deployment. It details supported software versions, patches, and configurations to ensure the platform performs well.
- Migrating
  The following topics show how to migrate an existing HCL Commerce Version 9.1 environment to Commerce+. The process consists of an initial migration of your database contents. This is followed by a code migration. Both are fully described.
- Operating
  The topics in this section focus on tasks that are performed by business users, marketers, and customer support representatives to connect with partners and attract and satisfy customers.
- Administering
  The site administrator performs the tasks needed to support day to day operations of the Commerce+ site.
- Extending
  Using Commerce+'s xC programming model, you can use HCL-provided extension points to extend existing Commerce logic. You can implement these extensions with the xC Customization toolkit provided by HCL. Commerce+ also provides Packaged Business Capability integrations that extend the product's reach and functionality.
- Securing
  These topics describe the security features of Commerce+ and how to configure these features.
  - Non-applicable security vulnerabilities
    The Commerce+ team has evaluated the following security vulnerabilities identified within the Commerce+ stack and determined there is no impact to default deployments.
  - Commerce+ security model
    Authentication is the process of verifying that users or applications are who they claim to be. In an Commerce+ system, authentication is required for all users and applications that access the system, except for guest customers.
  - Commerce+ authentication model
    The Commerce+ authentication model is based on the following concepts: challenge mechanisms, authentication mechanisms and user registries.
  - Authorization
    Commerce+ views access control or authorization as the process of verifying that users or applications have sufficient authority to access a resource. This section describes the details of several aspects of Commerce+ access control.
  - Hardening site security checklist
    To harden the security of your HCL Commerce site, you can enable and configure various security features. In addition, site customizations must always be made to comply with best practices as outlined in this document.
  - Site security considerations
    To enhance the security of your Commerce+ site, you can enable various features in Administration Console or in the Commerce+ configuration file.
    - Enabling password invalidation
      Password invalidation, when enabled, requires Commerce+ users to change their password if the user's password is expired. In this case, the user is redirected to a page where they are required to change their password. Users are not able to access any secure pages on the site until they change their password.
    - Encrypting data
      This section contains information about the important steps involved when ensuring the security of your site. There are different encryption options available including information on Key Locator Framework, where you encrypt your data, how to change your session encryption keys and how to develop custom code using EncryptionFactory.
    - Transport Layer Security (TLS) protocol Version 1.3
      Use the latest TLS security protocol to protect your site. This prevents attackers from exploiting weaknesses in older, less secure versions to steal sensitive data.
    - Enabling the X-Frame-Options header
      You can configure the X-Frame-Options header settings to help you protect your site against clickjacking. Clickjacking is a technique that tricks a web user into clicking a malicious site, thinking that it is your site. This malicious site can then reveal confidential information or take control of the user's computer.
    - Enabling security with HTTP headers
      You can use HTTP headers to pass security-oriented information between the server and client. Headers are available to prevent man-in-the-middle, cross-site scripting, content sniffing and clickjacking attacks.
    - Enabling cross-site scripting protection
      When enabled, cross-site scripting protection rejects any user requests that contain attributes (parameters) or strings that are designated as not allowable. You can also exclude commands from cross-site scripting protection by allowing the values of specified attributes for that particular command to contain prohibited strings. Cross-site scripting protection is enabled by default.
    - Enabling cross-site request forgery in Spring
      Cross-site request forgery (CSRF) is a type of malicious attack that tricks a user into sending unintended requests. For example, an attacker can trick an authenticated user into clicking a link to update their personal information. Commerce+ accepts this request as valid, as proper session cookies exist as part of the request.
    - Disabling cross-site scripting protection for the Commerce Lab
      When enabled, cross-site scripting protection rejects any user requests that contain attributes (parameters) or strings that are designated as not allowable. You can also exclude commands from cross-site scripting protection by allowing the values of specified attributes for that particular command to contain prohibited strings. Cross-site scripting protection is enabled by default, but you can disable it to match your security needs.
    - Enabling WhiteList data validation
      When enabled, WhiteList data validation ensures that when a URL command or view is run, the parameter values conform to a specified regular expression. For example, you can configure it so that the storeId must be an integer. When a WhiteList violation is detected, the request is changed to the ProhibCharEncodingErrorView view. WhiteList data validation is disabled by default.
    - Enabling cross-site request forgery protection in Struts
      Cross-site request forgery (CSRF) is a type of malicious attack that tricks a user into sending unintended requests. For example, an attacker can trick an authenticated user into clicking a link to update their personal information. Commerce+ accepts this request as valid, as proper session cookies exist as part of the request.
    - Enabling cross-site request forgery protection in REST
      Enabling cross-site request forgery (CSRF) protection is recommended when using REST APIs with cookies for authentication. If your REST API uses the WCToken or WCTrustedToken tokens for authentication, then additional CSRF protection is not required.
    - Enabling URL redirect filtering
      When you enable URL redirect filtering, Commerce+ rejects any requests that try to redirect to an unauthorized site. This feature is used to prevent phishing attacks where a link in an Commerce+ site sends the shopper to another site.
    - Enabling access logging
      When enabled, the access logging feature logs either all incoming requests to the Transaction server or only the requests resulting in access violations. Examples of access violations are authentication failure or insufficient authority to execute a command. When enabled, access logging allows an Commerce+ administrator to quickly identify security threats to the Commerce+ system.
    - Enabling SSL for outbound web services
      You can enable SSL for web services by using the Open Liberty Server administrative console for development and testing, and by using Run Engine commands for permanent configuration changes.
    - Encrypting data in custom code using EncryptionFactory
      EncryptionFactory is a factory class that initializes all of the encryption provider classes that are used at runtime for encrypting and decrypting data. All encryption providers must implement the com.ibm.commerce.foundation.common.util.encryption.EncryptionProvider interface.
    - Web server security considerations
      Be aware of the following security considerations for your web server and take the recommended actions to minimize any security exposure.
    - Setting up account related policies
      For enhanced security of your site, ensure that you are aware and up to date on all account related policies.
    - Enabling password-protected commands
      When the password-protected commands feature is enabled, Commerce+ requires registered users who are logged onto Commerce+ to enter their password before continuing a request that runs designated Commerce+ commands. When you configure password-protected commands, be aware of the consequences of specifying a command that can be run by generic and guest users. Configuring such commands as password-protected will prevent generic and guest customers from running them.
    - Configuring Reset Password to use long validation codes
      When a registered user requests a reset of a forgotten password, you can configure the Reset Password URL to send a randomly generated validation code instead of a temporary password. By default, this code can be up to 100 characters long.
    - Configuring Reset Password to use short validation codes
      When a customer requests a password change, you can configure the Reset Password function to email them a short, numeric validation code. Prior to Version 9.1.7.0, the validation code was long, up to 100 characters. You can still use the long-code validation code, however this approach is deprecated and will be discontinued in a future release.
    - Prevent privileged users from logging in externally
      The wc-server.xml file includes a customizable web server header. You can edit this header to control whether privileged users can log in to the store from external networks. This framework reduces the possibility of an external attack if an account with administrative level access, such as a customer service representative or site administrator, is compromised.
  - Session management
    Browsers and e-commerce sites use HTTP to communicate. HTTP is a stateless protocol, which means that each command is run independently without any knowledge of the commands that came before it. Because it is a stateless protocol, sessions must be managed between the browser side and the server side.
  - Quick reference to user IDs, passwords, and Web addresses
    Administration in the Commerce+ environment requires a variety of user IDs. These user IDs along with their requisite authorities are described in the following list. For the Commerce+ user IDs, the default passwords are identified.
- Performance
  Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of Commerce+ site performance.
- Troubleshooting
  Topics in the Troubleshooting section highlight common issues that are encountered with Commerce+, and how they can be addressed or mitigated.
- Reference
  Topics in the Reference section contain all of the Commerce+ reference documentation.

Transport Layer Security (TLS) protocol Version 1.3

Use the latest TLS security protocol to protect your site. This prevents attackers from exploiting weaknesses in older, less secure versions to steal sensitive data.

About this task

Transport Layer Security (TLS) is a cryptographic protocol designed for secure network communications. TLS 1.3 is the latest, and thus most secure, version of the specification.

Requiring TLSv 1.2 or higher is part of updating to NIST SP 800-131A security standards. Consider NIST SP 800-131A for more enhancements to site security.

Procedure

To enforce the use of TLSv 1.3 on your site, ensure that all supporting software is using TLSv 1.3:

It is recommended that you use TLSv1.3 so that you can support TLSv 1.2, and 1.3 for outbound communication. If you want to support only TLS 1.2 for outbound communication, then use TLSv1.3.
Open Liberty Server version 9.0.5.13 and later defaults to either the TLSv1.3 or TLSv1.2 outbound protocols.
Open Liberty Server versions earlier than 9.0.5.13 use SSL_TLSv2 by default, which supports TLS 1.0, 1.1, and 1.2 for outbound communication. Since TLS 1.0 and TLS 1.1 are insecure, it is recommended to update the configuration to TLSv1.3and TLSv1.2.
Use the Transaction server Run Engine commands to set the SSL protocol for SSL configuration.

Results

All communications on your site are now made through TLS 1.3 only.