Security
Pin the scripts you load from other sites
You load at least one script from another company, and nothing checks that the file is the one you expect, so a change on their side runs on your page as your code.
Why does it matter?
A script loaded from someone else's server runs with the full authority of your page: it can read every form, change what visitors see, and send data anywhere. An integrity attribute is a fingerprint. You publish the fingerprint of the exact file you intend to run, and the browser refuses to run it if the bytes differ. This is the one mechanism that keeps a compromised or swapped content network file from executing on your site.
How would you notice it?
- A security scan reports scripts from other origins without an integrity attribute.
- The recommendation names a count of scripts and how many lack a valid hash.
- Your page loads a library from a public content network.
How do you fix it?
We closed this finding on our own site, and we closed it by removing the cross-origin load, not by pinning a file we could not pin. Two notes.
Stage 1
- List the scripts that come from other sites. In the page source these are script tags whose src starts with a full address on a different domain than your own.
- Add the integrity and crossorigin attributes to each one, using the hash the provider publishes next to the file you load.
crossorigin is not optional here. Without it the browser cannot read the file to check the fingerprint and blocks the script instead, which looks like the library randomly broke.
The file nobody versions
Our site carried exactly one script from another origin, and it was the worst possible candidate for a fingerprint: the vendor edits that file in place, so a hash we computed today would block the script the day the vendor shipped a change, until we noticed and shipped a new hash, and that failure looks like the library randomly breaking. Check whether the file you are about to pin has stable, published versions. If it does not, remove the cross-origin load or accept the risk openly.
Source: Subresource integrity assessment on noblemarketglobal.com
<script src="https://cdn.example.com/lib.js"
integrity="sha384-REPLACE-WITH-THE-PUBLISHED-HASH"
crossorigin="anonymous"></script>Stage 2
- If the provider does not publish a hash, make one from the exact file and keep it beside the tag.
Treat the hash as part of the version number: when you update the library, regenerate the hash in the same edit. A stale hash blocks the script rather than warning you.
An attribute the browser never reads
That same script loads through a tag manager that runs off the main thread, and in that mode the browser never fetches the file itself, so an integrity attribute on it would be decoration that satisfies a checker while protecting nothing. The finding was closed by removing the cross-origin load entirely: we serve the vendor bytes from our own domain, forward only the needed parameter, and stream the body untouched. When a check forces a choice between an attribute that never runs and a load that never crosses origins, prefer the load you control.
Source: Same-origin analytics route verification on noblemarketglobal.com
# run against the downloaded file, then keep the result with the tag
openssl dgst -sha384 -binary lib.js | openssl base64 -AHow do you check it worked?
Confirm it worked
Reload a page that uses the script and confirm in the developer tools console that there are no integrity or cross-origin errors, then confirm whatever the script does still works. Re-run the Siege Test and confirm the Subresource Integrity recommendation is gone.