Loading...
WebShield Audit
Medium severity
Missing Subresource Integrity (SRI)
SRI ensures that files you load from CDNs (like jQuery or Bootstrap) haven't been tampered with.
Business risk
Supply Chain Attack: If you load `https://cdn.example.com/lib.js` and that CDN gets hacked, attackers can replace `lib.js` with malware. Your site will unwittingly execute this malware for every visitor. SRI prevents this by verifying the file's hash before execution.
Technical details
The `integrity` attribute contains a base64-encoded cryptographic hash. If the downloaded file doesn't match the hash, the browser blocks it. This is mandatory for high-security applications.
How to detect it
SRI is verifiable in the HTML itself. Every `<script src="...">` and `<link rel="stylesheet" href="...">` that loads from a cross-origin CDN should carry an `integrity` attribute and a `crossorigin` attribute. Missing `integrity` on a cross-origin asset is the finding.
Check rendered HTML for CDN assets without integrity
curl -s https://yourdomain.com | grep -E "src=\"https?://[^\"]+\"|href=\"https?://[^\"]+\"" | grep -v integrityGenerate an SRI hash for a given file
cat library.js | openssl dgst -sha384 -binary | openssl base64 -AOnline generator (paste URL)
https://www.srihash.org/Common pitfalls
- Using SRI without `crossorigin="anonymous"`. The browser will not check integrity on a cross-origin response unless CORS is properly configured, and the asset will load without verification.
- Applying SRI to self-hosted assets. It is not wrong, but it adds no security - SRI exists to protect against CDN tampering. Spend the effort on cross-origin assets.
- Forgetting to regenerate hashes when you upgrade the library. An integrity mismatch blocks the script entirely. Automate hash generation in your build pipeline.
- Pinning SRI to a `latest` URL. If the CDN updates the file, SRI will refuse to load it. Pin to a specific version (e.g., `jquery-3.7.1.min.js`) and regenerate the hash only when you intentionally upgrade.
- Using SHA-1 or MD5. SRI supports `sha256`, `sha384`, and `sha512`. `sha384` is the modern default; `sha256` is acceptable; `sha1`/`md5` are not.
Remediation guide
External references
Frequently asked questions
Which hash algorithm should I pick?
`sha384` is the standard choice and matches what MDN and most CDN documentation recommend. `sha512` is fine but offers no meaningful security gain for this use case. `sha256` works but is slightly weaker. Do not use `sha1` or `md5` - modern browsers will refuse them.
How do I handle CDN library updates?
Pin to a specific version in the URL, regenerate the SRI hash during your release process, and treat it like any other dependency bump. Tools like `npm`'s `integrity` field in `package-lock.json` handle this automatically for npm-hosted packages.
Does SRI protect against XSS?
No. SRI ensures a trusted file was loaded unmodified. It does not check what the file does. XSS protection comes from CSP. Use both together.
Keep going
Related guide
Missing Content Security Policy (CSP)
High severity · Content
Related guide
Missing Cross-Origin Isolation (COOP, COEP, CORP)
Low severity · Content
Related guide
Unsafe Links (Reverse Tabnabbing)
Medium severity · Content
Deep guide
CSP Safe Rollout: Report-Only to Enforce in Six Stages
Deploy a Content-Security-Policy that actually stops XSS - without shipping a broken site.
Free tool
CSP Checker
Validate your CSP in one scan - catches the mistakes linters miss.
Verify your fix
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.