Subresource Integrity: closing the CDN supply-chain gap

When your page includes a <script> from a CDN, you are not just loading code — you are delegating trust. That script runs in your origin with full access to the DOM, cookies and anything a user types. You are betting that the CDN serves exactly the file you expect, every time, forever.

That bet has lost before. CDN accounts get compromised, packages get hijacked, and a single altered file is served to every site that embeds it. This is a supply-chain attack, and a vibe-coded app that pulls analytics, fonts or a widget from a third party is squarely in range.

What SRI does

Subresource Integrity lets you pin the exact content of a third-party file. You add an integrity attribute containing a cryptographic hash of the expected file; the browser fetches the resource, hashes it, and refuses to execute it if the hash does not match. If the CDN serves a tampered file, it simply does not run — fail closed, not open.

• integrity="sha384-…" pins the hash of the script or stylesheet.
• crossorigin="anonymous" is required alongside it for cross-origin resources.
• Pair it with a CSP that restricts which origins may load scripts at all.

When it applies (and when it does not)

SRI is for third-party resources you reference by URL — a script tag pointing at a CDN. It is not meant for your own bundle, which your build already hashes and fingerprints. The risk it addresses is specifically "code I do not control, loaded at runtime from somewhere I do not control."

The fix

• For each external <script>/<link>, generate the hash (openssl, or your bundler's SRI plugin) and add integrity + crossorigin.
• Prefer self-hosting small dependencies — no third-party origin, no SRI needed.
• Re-generate hashes when you intentionally bump a pinned version; a mismatch should be a deliberate change, never a surprise.

VibeSafely lists every third-party script and style loaded without an integrity hash, so you know exactly which CDN dependencies are running on trust alone.