PCI 4.0 Compliance
The 24C release of Oracle Commerce includes support for the following DSS PCI 4.0 requirements for Storefront Classic (SF), Open Storefront Framework (OSF), and Agent Console:
Requirement 6.4.3 - All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
- A method is implemented to confirm each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written justification as to why each is necessary.
Requirement 11.6.1 - A change - and tamper - detection mechanism is deployed as follows:
- To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
- The mechanism is configured to evaluate the received HTTP header and payment page.
- The mechanism functions are performed as follows:
- At least once every seven days OR
- Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1)
Implementation
After enabling this feature, the Commerce Storefronts (SF and OSF) and Agent Console will return a Content-Security-Policy (CSP) response header that either contains the list of allowed domains to control what scripts are allowed to be included, or a nonce-source matching the nonce value of an inline script. e.g. Content-Security-Policy: 'unsafe-inline';script-src 'self' 'nonce-K81Z1OZuvJ2o9vxeQkal4gXj5X3HqLRpxo90pprLOsLVSFkpQawbHe8G+dZzV2fr' *.oraclecloud.com;
Oracle Commerce will add the following Content-Security-Policy (CSP) directives out of the box to make sure all JS / images / CSS / external connect requests are authorized.
Content |
CSP Directive |
Default Commerce Directive Value |
Comments |
---|---|---|---|
Script included via script tag |
script-src |
'self' |
The 'self' directive value allows the inclusion of all JS files from the same domain. This blocks JS files if they are not from the same domain. Content-Security-Policy: script-src 'self' <script src="/client.js"/> |
Inline script |
script-src |
'nonce-<RANDOM HASH>' |
A random nonce value is automatically included for inline scripts. Nonce values are dynamic and random for every HTTP request. Content-Security-Policy: script-src 'nonce-K81Z1OZuvJ2o9vxeQk' <script nonce="K81Z1OZuvJ2o9vxeQk"> window.state={'clientRepository':{}} </script> |
External script |
script-src |
The domain name of the external script source |
The domain of the externally hosted script is added to the CSP header as a script-src value when configured in the Page Tags section of the Admin UI. Another option is to generate an integrity hash for the included script file and add this to the CSP header. Content-Security-Policy: script-src '*.someotherdomain.com' <script src="www.someotherdomain.com/script.js"> Content-Security-Policy: script-src ' C6RzsynM9kWDrMNeT87bh' <script src="https://someotherdomain.com/script.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh"/> |
XHR requests |
connect-src |
'self' |
The 'self' directive value allows all XHR requests to the same domain. Content-Security-Policy: connect-src 'self' |
External XHR requests |
connect-src |
None |
For XHR requests to external domains, the domains must be specified by the customer to be added to the CSP header. Content-Security-Policy: connect-src '*.someotherdomain.com' |
Reporting |
report-uri |
Storefront -/ccstoreui/v1/logging/logCSPErrors Agent- /ccagent/v1/logging/logCSPErrors |
Merchants are to provide URL to report violations of the Content Security Policy. Default values are for internal monitoring purposes. |
The following instructions apply to Storefront Classic, Open Storefront Framework, and Agent Console:
- Enabling the PCI compliance setting will automatically update the CSP header with OOTB default values. Any customization to the CSP response header will continue to behave as before.
- When the PCI compliance setting is enabled, the CSP header for each site will include domains from all OOTB services. As there is no site context for Agent, the CSP header for the Agent Console will have domains from all OOTB services.
- All other externally hosted resources (Javascript, images, CSS, external XHR requests) and configured site/app (Agent) integrations will have to be updated manually as described in section External Source CSP Configuration of this document.
- When a Page Tags setting or a service is disabled or deleted, the response header will not have the corresponding URL in the CSP.
- Disabling the PCI 4.0 compliance setting will not calculate the OOTB default value for the CSP header from all sites/app (Agent). The customized CSP, if present, will continue to exist for the sites.
- Reporting for CSP violations is supported via the 'report-uri' directive. Merchants must configure report-uri to use their endpoint for logging CSP violations for their sites/app (Agent) to meet the change and tamper detection requirement. Please refer to the section External Source CSP Configuration of this document.
The following instructions apply only to Storefront Classic:
- Response headers will have a CSP with a nonce value for script-src, script-src-elem, and script-src-attr directives, if present, to allow OOTB inline JS/styling.
- The CSP header will automatically include domains from script tags defined in the Page Tags setting of the Admin UI, if a src attribute is present. If the src attribute is missing, then the script tag will render with an automatically generated nonce attribute when a page document is generated.
- For hard-coded script tags in widgets that include externally hosted files, customers are responsible for configuring the CSP manually with the external domains. See External Source CSP Configuration.
- Customers who have customized the OOTB index.jsp must merge their changes with the latest version on index.jsp included with 24C.
External Source CSP Configuration
If externally hosted JS, CSS, image, etc. files are used in custom widgets or plugins, the external domains of those files should be added manually to the CSP header. These can be configured via the updateResponseHeaders (/ccadmin/v1/merchant/responseHeaders) API for Storefront Classic and OSF. For Agent, these can be configured via the updateAgentResponseHeaders (/ccagent/v1/merchant/agentResponseHeaders) API. Please note that updateAgentResponseHeaders does not have a site context. Please refer to the REST API documentation for Oracle Commerce for more information.
For externally hosted JS files, an integrity hash value can be optionally added to the CSP.
PCI 4.0 introduces several new features designed to help organizations better protect cardholder data in the face of evolving threats.
Steps to Enable
To enable this feature, set enablePciCompliance to true from the updateCloudConfiguration (/ccadmin/v1/merchant/cloudConfiguration) API. Please refer to the REST API documentation for Oracle Commerce for more information. This is sufficient to enable PCI compliance in both Storefront Classic and Agent.
To enable the PCI 4.0 compliance on Open Storefront Framework(OSF), the following additional step needs to be performed:
- Update package.json of the OSF application (e.g: core-commerce-reference-store/package.json) with the following configurations under "occ".
"occ": {
"pci": {
"enableSRI": true,
"enableSRIForExtensions": true
}
}
Setting |
Description |
---|---|
enableSRI |
This setting enables the CSP header in the OSF application’s server-side rendering (SSR) response. |
enableSRIForExtensions (Optional) |
This setting enables OSF to read <script> tags from the following locations:
OSF parses the script tag src values to get the domains of the JS files and automatically updates the "Content-Security-Policy" header. OSF generates a unique nonce value in the CSP header for HTTP requests and gets appended to inline "<script>" tags which allows the scripts to be loaded by the browser. |
Key Resources
Please refer to these external links on more information on PCI standards and Content Security Policy