Check your external resources for SRI hashes

SiteCurl checks every external script and stylesheet on your pages for the integrity attribute. External means hosted on a different domain than your site. Files from your own server are skipped because you control them directly.

The integrity attribute contains a cryptographic hash of the file's expected content. When the browser downloads the file, it computes the hash and compares it to the expected value. If they do not match, the browser refuses to use the file. This catches tampering, whether from a compromised CDN, a man-in-the-middle attack, or an accidental change on the hosting server.

SiteCurl reports how many external resources have SRI hashes and lists the ones that do not. If your site loads all scripts and styles from your own server, it passes automatically because there are no external resources to verify.

Most websites load at least some files from external servers. jQuery from a CDN, Google Fonts, analytics libraries, payment scripts. Each of these files runs with full access to your page. If an attacker compromises the CDN or the external server, they can replace the file with a malicious version. Every site loading that file executes the attacker's code instead.

This is not theoretical. In 2018, an attacker compromised a widely used JavaScript library hosted on a CDN and injected code that stole cryptocurrency wallet credentials from thousands of websites. The sites had done nothing wrong. They loaded a trusted library from a trusted CDN. But the CDN was compromised, and without SRI, the browsers had no way to know the file had changed.

SRI works by locking the file to a specific version. You generate a hash of the file (sha256, sha384, or sha512) and include it in the HTML tag. If the file changes by even one byte, the hash will not match and the browser blocks it. Your page may show an error from the missing resource, but it will not run the tampered code.

The tradeoff is that SRI breaks when the external file is intentionally updated. If the CDN updates the library to a new version, the hash no longer matches. This means you need to update the hash in your HTML when you upgrade libraries. For most sites, this is a small price for the protection it provides.

External scripts run with the same permissions as your own code. A compromised CDN script can read cookies, capture form input, redirect visitors, and exfiltrate data. Without SRI, your site trusts that every external server will always serve the correct file.

SRI is especially important for sites that handle sensitive data. If your page loads a payment script from an external CDN without SRI, a compromised CDN could swap in a script that captures credit card numbers. SRI prevents the tampered script from running.

Security auditors and penetration testers flag missing SRI as a finding. For SaaS products selling to enterprise customers, SRI on external resources is a baseline expectation in vendor security questionnaires.

E-commerce sites loading payment libraries, analytics scripts, and CDN-hosted frameworks are the most exposed. Each external script without SRI is a trust dependency on a server you do not control.

SaaS products embedding third-party widgets (chat, analytics, feature flags) load multiple external scripts per page. Each one is a potential entry point if the external server is compromised.

Marketing sites and blogs often load fonts, social sharing scripts, and analytics from external CDNs. While the risk is lower than for sites handling payment data, a compromised script can still redirect visitors or inject unwanted content.

Step 1: Identify external resources. Run a SiteCurl scan to see which external scripts and stylesheets are missing SRI hashes. The scan lists specific URLs so you know exactly which files to address.

Step 2: Generate SRI hashes. Go to srihash.org and paste the URL of the external file. It generates the integrity attribute value for you. You can also generate hashes locally with openssl dgst -sha384 -binary file.js | openssl base64 -A.

Step 3: Add the integrity attribute. Add the generated hash to your script or link tag. Example: <script src="https://cdn.example.com/lib.js" integrity="sha384-abc123..." crossorigin="anonymous"></script>. The crossorigin="anonymous" attribute is required for SRI to work on cross-origin resources.

Step 4: Pin your library versions. SRI hashes are tied to a specific file. Use versioned URLs (like /lib@3.6.0/lib.min.js) instead of latest or unversioned URLs. This prevents the hash from breaking when the library releases a new version.

Step 5: Update hashes when upgrading. When you update an external library, generate a new SRI hash for the new version. This is the tradeoff: SRI requires a manual step when upgrading, but it guarantees the file has not been altered.

Mistake 1. Forgetting the crossorigin attribute. SRI requires crossorigin="anonymous" on cross-origin resources. Without it, the browser may not perform the integrity check. Always include both attributes.

Mistake 2. Using unversioned CDN URLs. URLs like /lib/latest/lib.min.js change content when the library updates, breaking the SRI hash. Pin to a specific version so the file stays constant.

Mistake 3. Only adding SRI to scripts, not stylesheets. A compromised stylesheet can inject content, hide elements, or exfiltrate data through CSS. Add SRI to both <script> and <link rel="stylesheet"> tags.

Mistake 4. Skipping SRI for 'trusted' CDNs. No CDN is immune to compromise. Even large providers have been breached. SRI protects you regardless of how trustworthy the CDN appears today.

After adding SRI hashes, run another SiteCurl scan. The subresource integrity check should pass for all external resources. You can also verify manually: right-click the page, view source, and search for integrity= on your script and link tags.

To test that SRI is working, temporarily change one character in the integrity hash and reload the page. The browser should block the resource and show an error in the console. If the file still loads with a wrong hash, the SRI setup is not working correctly.

SRI hashes verify that files from external servers have not been tampered with. Every external script and stylesheet on your site should have an integrity attribute. Generate hashes at srihash.org, pin your library versions, and include the crossorigin attribute. It is a one-time setup per library that guards against CDN compromise.