- Enabling password invalidation
Password invalidation, when enabled, requires Commerce+ Transaction Server 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+ Transaction Server 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+ Transaction Server 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+ Transaction Server 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+ Transaction Server 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+ Transaction Server administrator to quickly identify security threats to the Commerce+ Transaction Server 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+ Transaction Server requires registered users who are logged onto Commerce+ Transaction Server to enter their password before continuing a request that runs designated Commerce+ Transaction Server 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.