Check your external resources for SRI hashes

SiteCurl checks each external script and stylesheet on your pages for the integrity field. External means hosted on a domain other than yours. Files from your own server are skipped since you control them directly.

The integrity field holds a hash of the file's expected content. When the browser grabs the file, it runs the hash and compares. If they do not match, the browser blocks the file. This catches tampering from a hacked CDN, a network attack, or a bad change on the host server.

SiteCurl shows how many external files have SRI hashes and lists those that do not. If your site loads all scripts and styles from your own server, it passes on its own since there are no external files to check.

Most sites load at least some files from outside servers. jQuery from a CDN, Google Fonts, tracking tools, payment scripts. Each file runs with full access to your page. If an attacker takes over the CDN, they can swap the file for a bad version. Each site loading that file runs the bad code instead.

This is not just theory. In 2018, an attacker took over a widely used JS library on a CDN and put in code that stole crypto wallet keys from thousands of sites. Those sites did nothing wrong. They loaded a trusted file from a trusted CDN. But the CDN was hacked, and without SRI, browsers had no way to know the file had changed.

SRI works by locking the file to one version. You make a hash of the file (sha256, sha384, or sha512) and put 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 file, but it will not run the bad code.

The cost is that SRI breaks when the file is changed on purpose. If the CDN ships a new version, the hash will not match. You need to update the hash in your HTML when you upgrade. For most sites, this is a small price for the safety it gives.

External scripts run with the same rights as your own code. A hacked CDN script can read cookies, grab form input, send users away, and steal data. Without SRI, your site trusts that each outside server will always serve the right file.

SRI matters most for sites that handle private data. If your page loads a payment script from a CDN without SRI, a hacked CDN could swap in a script that grabs card numbers. SRI stops the bad script from running.

Pen testers flag missing SRI as a finding. For SaaS tools sold to big buyers, SRI on outside files is a basic item in vendor security reviews.

Online stores loading payment tools, tracking scripts, and CDN-hosted code are most exposed. Each outside script without SRI is a trust link to a server you do not control.

SaaS tools that embed third-party widgets (chat, tracking, feature flags) load many outside scripts per page. Each one is a way in if the outside server is hacked.

Marketing sites and blogs often load fonts, social sharing scripts, and tracking from CDNs. While the risk is lower than for sites with payment data, a hacked script can still send users away or inject bad content.

Step 1: Find outside files. Run a SiteCurl scan to see which external scripts and stylesheets lack SRI hashes. The scan lists URLs so you know which files to fix.

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

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

Step 4: Pin your library versions. SRI hashes are tied to one file. Use versioned URLs (like /[email protected]/lib.min.js) instead of latest or plain URLs. This stops the hash from breaking when the library ships a new version.

Step 5: Update hashes when upgrading. When you update a library, make a new SRI hash for the new version. This is the cost: SRI needs a manual step when upgrading, but it proves the file has not been changed.

Mistake 1. Skipping the crossorigin field. SRI needs crossorigin="anonymous" on cross-origin files. Without it, the browser may not run the hash check. Always include both fields.

Mistake 2. Using URLs with no version. URLs like /lib/latest/lib.min.js change content when the library updates, breaking the SRI hash. Pin to a set version so the file stays the same.

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

Mistake 4. Skipping SRI for 'trusted' CDNs. No CDN is safe from attack. Even large ones have been hacked. SRI guards you no matter how trusted the CDN seems today.

After adding SRI hashes, run a new SiteCurl scan. The SRI check should pass for all outside files. You can also check by hand: right-click the page, view source, and search for integrity= on your script and link tags.

To test that SRI works, change one letter in the hash and reload the page. The browser should block the file and show an error in the console. If the file still loads with a wrong hash, the SRI setup is not right.

SRI hashes prove that files from outside servers have not been changed. Each external script and stylesheet on your site should have an integrity field. Make hashes at srihash.org, pin your library versions, and include the crossorigin field. It is a one-time setup per library that guards against CDN attacks.