Subresource Integrity: pin third-party scripts so a hacked CDN can't hijack your page
An integrity hash makes the browser verify every third-party script before running it, so a compromised CDN gets blocked instead of executed
The threat
You load a script or stylesheet from a third-party CDN, <script src="https://cdn.example.com/lib.js">. The https protects that file in transit, but it says nothing about whether the file itself is trustworthy. If the CDN is ever compromised, or someone gains push access to that library, the tampered version is served straight to your visitors and runs with full access to your page. It can read what people type, skim card numbers at checkout (the Magecart pattern), or ride a live session. You get no warning, because from your side nothing changed: same URL, same site.
Subresource Integrity (SRI) fixes the gap by pinning the exact file you expect. You add a cryptographic hash of the known-good file; the browser downloads the resource, hashes it, and refuses to run it if the hashes do not match. A tampered file simply does not execute, so a CDN compromise turns into a broken feature instead of a breach.
The exact fix
Add integrity="sha384-..." and crossorigin="anonymous" to third-party <script> and <link> tags.
<script
src="https://cdn.example.com/lib@1.2.3/dist/lib.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
<link
rel="stylesheet"
href="https://cdn.example.com/lib@1.2.3/dist/lib.min.css"
integrity="sha384-BASE64HASH"
crossorigin="anonymous">
Where the hash comes from. Many CDNs publish the SRI hash right next to the file with a copy button. Or generate it yourself from the exact file you are pinning:
curl -s https://cdn.example.com/lib@1.2.3/dist/lib.min.js \
| openssl dgst -sha384 -binary \
| openssl base64 -A
Prepend sha384- to the output and drop it into integrity.
crossorigin="anonymous"is required, not optional. The browser needs a proper cross-origin (CORS) response to be allowed to read and hash a third-party file, andanonymousfetches it without sending credentials.- Stronger option: self-host the library. Download the vetted version into your own bundle and serve it from your own origin. A third-party CDN then has nothing to tamper with, and you drop an outside dependency and connection at the same time. SRI is the right fix when you must use the CDN; self-hosting removes the risk entirely.
SRI only works on version-pinned, immutable URLs. If you point at a rolling
.../lib/latest/lib.js, the file legitimately changes and your hash will break on the next update, taking the script down with it. Pin a specific version (lib@1.2.3), or leave SRI off that one tag rather than gambling on a URL whose contents you do not control.
Verify it
curl -s https://yourdomain.com | grep -i 'integrity='
Every third-party <script> and <link> in the output should carry an integrity="sha384-..." attribute. As a live test, load the page with DevTools open: if a hash is ever wrong, the Console logs an integrity failure and the resource is blocked, so a clean Console means the hashes match and the guard is active.
Proof
The ApeCyber scanner reads your public HTML the way a browser does, from the outside, touching nothing, and flags third-party scripts that load with no integrity pin. Holding this kind of supply-chain discipline is part of how apecyber.com and dev3lop.com reached A / 100. Around ten minutes per site, a clean โ4 off the posture score, and a hacked CDN gets blocked instead of trusted.