CSP decides which sources and inline code a page may run. SRI checks that a file from an allowed source still has the bytes you reviewed. CSP stops code from places you never approved, and SRI stops a changed file from a place you did. They cover different failures, so most sites benefit from both.
Side by side
| Question | CSP | SRI |
|---|---|---|
| What is it | A response header or meta element with directives | An integrity attribute on a tag |
| What does it check | Origin, nonce, hash, inline use | Hash of the fetched bytes |
| Stops injected inline script | Yes, if unsafe-inline is avoided | No |
| Stops a script from an unlisted host | Yes | Not directly |
| Stops a tampered file on a trusted CDN | Not by itself | Yes |
| Works on dynamic, changing scripts | Yes, via nonce or strict-dynamic | No, a hash pins one version |
| Needs CORS on the remote file | No | Yes |
What CSP is good at
MDN calls CSP primarily a defense against cross-site scripting. By controlling resource loading it can block script tags that link to malicious sources, inline script blocks, inline event handlers, javascript: URLs and eval-like calls. MDN is clear that it does not replace input sanitization. It is defense in depth.
What SRI is good at
MDN describes SRI as a way to defend against supply chain attacks where a third party host is compromised. The browser downloads the file, hashes it and compares it with the integrity value. A mismatch means the script does not run.
The gap each leaves
Say you allow cdn.example.net in CSP because you load a library from there. If that CDN account is compromised and the file is replaced, CSP still allows it because the host is trusted. Only an SRI hash would catch the change.
Now say you pin every script with SRI, but an attacker finds a cross-site scripting flaw and injects an inline script. SRI says nothing about inline code without a src. A strict CSP would block it.
How they combine
MDN's hash-based CSP guidance actually uses both: external scripts allowed by hash also need a matching integrity attribute. A nonce based policy with strict-dynamic is common for pages with many dependencies, with SRI on the static files you can pin.
Setup order that works
- Pin and hash everything you can, see how to add SRI.
- Roll out a strict CSP in report-only mode, see CSP report-only rollout steps.
- Enforce CSP, then consider Integrity-Policy to require hashes, see the Integrity-Policy header.
- Scan your npm dependencies so the code in your own bundle is covered too.
Safeguard does that last step: SBOM and dependency scanning with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings about a running web app, such as missing headers, are presented.
Quick check
If I have CSP, do I still need SRI?
Often yes. CSP trusts a host, so a tampered file from a trusted host passes. SRI catches the changed bytes.
If I have SRI, do I still need CSP?
Yes. SRI does not cover inline injected script or unlisted hosts, which CSP limits.
Sources
- MDN, Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
Last reviewed: 19 October 2026.
