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 it matters
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 you would 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.
What to do
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.
<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.
# run against the downloaded file, then keep the result with the tag
openssl dgst -sha384 -binary lib.js | openssl base64 -AHow to 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.