Script Integrity with Subresource Integrity (SRI) for PCI DSS 6.4.3

Script Integrity with Subresource Integrity (PCI DSS 6.4.3)

PCI DSS v4.0 Requirement 6.4.3 requires all scripts on payment pages to have integrity controls. The primary method for achieving this is Subresource Integrity (SRI), a browser feature designed to ensure that scripts loaded by a web page have not been tampered with.

What is Subresource Integrity (SRI)?

Subresource Integrity is a security mechanism built into modern browsers that protects against unauthorized modifications to scripts. It works by requiring a cryptographic hash (such as SHA-256, SHA-384, or SHA-512) of the exact file content. This hash is computed in advance and embedded in the HTML tag that loads the script. When the browser fetches the script, it recalculates the hash and compares it to the one provided. If the hashes do not match, the browser blocks the script from executing. This ensures that resources fetched from third parties are delivered without manipulation, providing a robust defense against attacks such as CDN compromise or man-in-the-middle (MitM) tampering.

Implementing SRI for Static Scripts

For static scripts-files that do not change with every deployment-implementing SRI involves a straightforward process:

• Obtain the Script: Identify and fetch the exact script file (such as a specific version of a JavaScript library).
• Compute the Hash: Use a secure hashing algorithm. For example, to generate a SHA-384 hash:

openssl dgst -sha384 -binary path/to/script.js | openssl base64 -A

• Add the Integrity Attribute: Embed the script in your HTML with the integrity attribute set to the computed hash, and crossorigin="anonymous" if loading from another domain:

<script src="https://code.jquery.com/jquery-3.6.0.min.js"
        integrity="sha384-BASE64_HASH_HERE"
        crossorigin="anonymous"></script>

• Serve Over HTTPS: SRI requires scripts to be delivered over HTTPS. If loading from a CDN or third-party domain, ensure the server sets the appropriate Access-Control-Allow-Origin header.

Once implemented, any change to the script-even a single character-produces a different hash, causing the browser to block the script. This mechanism effectively prevents modified or malicious versions of the script from executing.

Example:

<script src="https://code.jquery.com/jquery-3.6.0.min.js"
        integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yb/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC"
        crossorigin="anonymous"></script>

If the script on the CDN is altered, the hash will not match, and the browser will refuse to execute it.

Benefits of SRI

• Tamper Detection: SRI ensures the script is exactly as expected. Any unauthorized change is immediately detected and blocked, creating a cryptographic fingerprint for browsers to verify.
• Defense Against Compromised Hosts: If a CDN or third-party server is compromised, SRI prevents the injection of malicious code by refusing to load altered scripts.
• Mitigation of XSS/Injection: Only scripts matching the approved hash can run, blocking attempts to inject malicious code-even if an attacker hijacks a connection or alters a hosted file.
• Trusted Third-Party Code: SRI boosts confidence in external libraries by ensuring they are delivered exactly as intended, free from unauthorized modifications.
• User Safety and Site Integrity: Preventing the execution of altered scripts directly protects users and maintains site integrity.
• Ease of Implementation: Adding SRI hashes is straightforward, with many build tools and online generators available. SRI adds negligible runtime overhead.
• Compliance Support: SRI directly addresses PCI DSS’s requirements for script integrity, making it a clear path to compliance for static scripts.

Applying SRI to All Eligible Scripts

For maximum protection, apply SRI to every static script. PCI guidance emphasizes that SRI is effective only for static scripts-those whose contents do not change frequently. By ensuring all unchanging scripts are cryptographically verified in the browser, you establish the strongest defense against tampering.

Handling Dynamic or Third-Party Scripts

Not all scripts are suitable for SRI. Some change frequently or are controlled by third parties:

• Dynamic Scripts: For scripts that change often (such as analytics or A/B testing libraries), static SRI hashes are not feasible. Instead, implement active monitoring-use automated tools to fetch the live script, compare it against a known-good baseline, and alert on any unexpected changes.
• Third-Party Scripts: If you cannot control updates to a script (e.g., payment widgets or analytics from vendors), treat them as dynamic and monitor them continuously. Some security solutions can automate this process, flagging even minor unauthorized alterations.
• Documentation and Justification: PCI DSS expects organizations to document any script that cannot use SRI, explaining why SRI is not used and describing the alternative monitoring process in place.
• Automation and Tooling: Automate monitoring wherever possible, using custom scripts or commercial solutions that regularly fetch and verify scripts.

For dynamic or third-party scripts, SRI alone is not sufficient. Combine frequent scanning, hashing comparisons, and behavioral analysis to ensure integrity. If any change is detected, review the script immediately. Maintaining robust monitoring and documentation for these scripts fulfills PCI DSS’s intent for script integrity controls.

Conclusion

Subresource Integrity is a powerful and efficient tool for ensuring script integrity under PCI DSS 6.4.3. By embedding cryptographic hashes in your HTML, you make static script includes tamper-evident, protecting against CDN compromises, MitM attacks, and unauthorized code execution. For best results, apply SRI to all static scripts. For scripts that change frequently or are managed by third parties, supplement SRI with active monitoring and integrity checks, and document your approach as required by PCI DSS. Adopting SRI wherever possible-and responsibly monitoring the rest-ensures your payment pages maintain script integrity and comply with PCI DSS requirements.