Subresource Integrity (SRI)
debt(d5/e1/b3/t5)
Closest to 'specialist tool catches it' (d5). The detection_hints list Lighthouse, OWASP ZAP, and Semgrep — all specialist or audit-class tools rather than default linters or compilers. Missing SRI on CDN resources won't be flagged by a standard linter pass; you need to run a dedicated security scanner or audit tool to surface it.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix is explicit: add integrity='sha384-{hash}' and crossorigin='anonymous' to each tag, using srihash.org to generate the hash. Each fix is a single attribute addition per tag — minimal mechanical effort even if there are multiple tags.
Closest to 'localised tax' (b3). SRI applies only to the web context and specifically to CDN-hosted <script> and <link> tags. The ongoing tax is remembering to regenerate hashes when library versions change, but this burden is confined to front-end asset management and doesn't ripple into broader application architecture or other components.
Closest to 'notable trap' (t5). The misconception field confirms the canonical wrong belief: 'Loading scripts from a reputable CDN is safe without SRI.' Common mistakes reinforce secondary traps — not regenerating hashes on version updates, using SRI over HTTP where MITM can bypass it, and omitting stylesheets. These are documented gotchas that competent developers regularly miss, placing it solidly at t5.
Also Known As
TL;DR
Explanation
SRI (W3C spec) adds an integrity attribute to <script> and <link> tags containing a base64-encoded SHA-256/384/512 hash of the expected file content. The browser refuses to execute or apply the resource if the downloaded content doesn't match. This prevents supply chain attacks where a CDN is compromised and serves a malicious version of a library. In PHP applications, generate SRI hashes with openssl_digest() or use build tools, and always combine SRI with crossorigin='anonymous'.
Common Misconception
Why It Matters
Common Mistakes
- Adding SRI hashes once at setup but not regenerating them when the library version updates.
- Using SRI on scripts loaded over HTTP — without HTTPS the hash check can be bypassed by MITM.
- Not adding SRI to stylesheets — CSS can also exfiltrate data via attribute selectors.
- Generating SRI hashes from a locally cached copy that differs from what the CDN actually serves.
Avoid When
- Do not use SRI for first-party resources you host yourself — it adds no security benefit for resources under your own control.
- Do not skip SRI for CDN-hosted JavaScript — a compromised CDN can inject malicious code into every page that loads it.
When To Use
- Add integrity and crossorigin attributes to all third-party <script> and <link> tags loaded from CDNs.
- Generate SRI hashes at build time and pin them — regenerate when updating the CDN resource version.
Code Examples
<script src="https://cdn.example.com/jquery.min.js"></script><script src="https://cdn.example.com/jquery.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>