Subresource Integrity: Your First Line of Defense for Payment Page Scripts

Subresource Integrity (SRI) is a browser security feature defined in the W3C specification that lets you pin an external script to a specific cryptographic hash. If the script file is modified on the CDN - whether by an attacker or by an unintended deployment - the browser refuses to execute it entirely. No execution means no skimming, no data theft, and no Magecart attack.

How SRI works

You add an integrity attribute to your script tag containing a hash algorithm prefix and the base64-encoded digest of the file you expect:

<script src="https://cdn.example.com/payment-lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

When the browser fetches the file, it computes the hash of the response body and compares it to the declared value. If they do not match, the script is blocked and an error is logged. The check happens client-side, in every user's browser, on every page load.

Generating the hash

You can generate the hash from the command line:

cat payment-lib.js | openssl dgst -sha384 -binary | openssl base64 -A

Or use an online tool like srihash.org. The W3C recommends SHA-384 as a good balance between security and performance. SHA-512 is also acceptable; SHA-256 is supported but less preferred for new implementations.

Browser support and crossorigin

SRI is supported in all modern browsers. The crossorigin="anonymous" attribute is required when the script is loaded from a different origin - without it, the browser cannot read the response to compute the hash, and SRI validation fails silently.

Limitations of SRI alone

SRI protects against tampered external scripts, but it has important gaps you need to be aware of:

• Inline scripts are not covered. SRI only applies to external resources. Attackers who can modify your HTML can inject an inline script block that SRI does not check.
• Scripts without an integrity attribute are not protected. If you load any external script without SRI, it is an unprotected attack surface even if other scripts on the page use SRI.
• SRI does not alert you. When a browser blocks a script due to an SRI mismatch, the user silently loses functionality. You do not receive any notification that your CDN has been compromised.
• Dynamic script injection bypasses SRI. If an attacker gains access to your server and injects a script via a legitimate deployment, they can update the integrity hash at the same time, making SRI useless.

SRI and PCI DSS 4.0

PCI DSS 4.0 Requirement 11.6.1 does not require SRI specifically, but it does require weekly monitoring of all scripts on payment pages. Shieldome checks your SRI attributes as part of each scan - verifying that the declared hash still matches the actual content of each external script file. An SRI failure triggers an alert even if the script has not changed in your own baseline, because it means the CDN is now serving a different file than the one the attribute was generated for.

The most robust approach is to combine SRI on all external scripts with Shieldome's monitoring, which additionally covers inline scripts and any scripts that do not yet have SRI attributes.

Practical checklist

1. Audit every script tag on your checkout page. List every external URL.
2. Generate SHA-384 hashes for each external script and add integrity attributes.
3. Add crossorigin="anonymous" to all externally loaded scripts.
4. Set up a Content Security Policy that restricts which script sources are allowed.
5. Enable weekly automated monitoring (Shieldome's PCI Monitoring) to catch any changes to inline scripts and external scripts that slip past SRI.

Read the full PCI Monitoring documentation or start a free trial to baseline your checkout page in under two minutes.