Want to learn more?
Learn how SRI hashes protect against tampered CDN scripts and ensure third-party resource integrity.
Read the guideSecuring Third-Party Scripts?
Our DevSecOps team implements SRI, CSP, and other defenses against supply chain attacks.
What Is Subresource Integrity (SRI)
Subresource Integrity (SRI) is a web security feature that allows browsers to verify that files fetched from CDNs and third-party servers have not been tampered with. By adding a cryptographic hash to <script> and <link> tags, SRI ensures that the browser only executes resources that match the expected content. If a CDN is compromised and serves malicious code, SRI-protected pages will refuse to load the altered resource.
Supply chain attacks targeting CDN-hosted JavaScript libraries are a growing threat. The 2018 event-stream incident, the 2021 ua-parser-js compromise, and numerous attacks on npm packages demonstrate that third-party code can be weaponized. SRI is the browser-native defense against these attacks—no additional libraries or services required.
How SRI Works
SRI uses cryptographic hash functions to create a fingerprint of the expected file contents:
- Generate hash: Compute the SHA-256, SHA-384, or SHA-512 hash of the resource file
- Add integrity attribute: Include the hash in the HTML tag's
integrityattribute - Browser verifies: When the browser downloads the resource, it computes its hash and compares it to the declared value
- Block on mismatch: If the hashes don't match, the browser refuses to execute the resource
Example:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
crossorigin="anonymous"></script>
| Hash Algorithm | Output Length | Recommendation |
|---|---|---|
| SHA-256 | 256 bits (64 hex chars) | Minimum acceptable |
| SHA-384 | 384 bits (96 hex chars) | Recommended (best balance) |
| SHA-512 | 512 bits (128 hex chars) | Maximum security |
Multiple hashes: You can include multiple hashes for forward compatibility when updating resources:
integrity="sha384-abc123... sha384-def456..."
The crossorigin="anonymous" attribute is required for SRI on cross-origin resources; without it, the browser cannot verify the hash.
Common Use Cases
- CDN-hosted libraries: Protect jQuery, Bootstrap, React, and other libraries loaded from public CDNs
- Third-party scripts: Verify analytics, chat widgets, and advertising scripts haven't been modified
- Compliance requirements: PCI-DSS 4.0 requires integrity verification for payment page scripts
- Supply chain security: Defend against compromised CDN infrastructure or npm package hijacking
- Build pipeline verification: Generate SRI hashes during CI/CD and embed them in production HTML
Best Practices
- Use SHA-384 as the minimum — SHA-256 is acceptable but SHA-384 is the recommended default for SRI hashes
- Always include crossorigin="anonymous" — Required for cross-origin resources; without it, SRI verification silently fails
- Regenerate hashes when updating libraries — Every version change produces a different hash; automate this in your build process
- Use SRI for all CDN resources — Apply integrity attributes to every
<script>and<link rel="stylesheet">loaded from third-party origins - Combine with Content Security Policy — Use CSP's
require-sri-fordirective to mandate SRI for all scripts and styles on your pages
References & Citations
- MDN Web Docs. (2024). Subresource Integrity. Retrieved from https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity (accessed January 2025)
- W3C. (2016). Subresource Integrity Specification. Retrieved from https://www.w3.org/TR/SRI/ (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
Frequently Asked Questions
Common questions about the SRI Hash Generator
Subresource Integrity (SRI) ensures external resources (CDN JS/CSS) have not been tampered with. Browser verifies file hash matches integrity attribute before executing. Example: script with src attribute pointing to https://cdn.example.com/lib.js with integrity sha384-abc123 and crossorigin anonymous. If file modified (CDN compromise, MITM attack), hash will not match and browser blocks execution. Benefits: prevent CDN compromise, detect file modifications, supply chain security, compliance requirements (PCI DSS). Required for: external resources from CDN, third-party libraries, cross-origin files. W3C standard, supported by all modern browsers. This tool generates SRI hashes for any JS/CSS file instantly.
SRI supports SHA-256, SHA-384, SHA-512. Recommendations: SHA-384 most common (balance of security and size), SHA-512 maximum security (longer hash), SHA-256 faster but less secure (still acceptable). You can specify multiple: integrity="sha384-abc123 sha512-def456" (browser uses strongest it supports). Performance: negligible difference for small files, SHA-384 recommended by most CDNs (jsdelivr, cdnjs). Hash format: algorithm-base64hash. Example: "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC". Security: all three are cryptographically secure for SRI purpose. This tool generates all three algorithms - choose based on your security policy.
Add integrity and crossorigin attributes to script/link tags. Steps: 1) Get hash from CDN (many provide it) or generate with this tool. 2) Add to HTML: <script src="https://cdn.jsdelivr.net/npm/vue@3" integrity="sha384-..." crossorigin="anonymous"></script>. 3) Test: browser console shows error if hash mismatch. Requirements: crossorigin attribute required (CORS), HTTPS only (SRI does not work on HTTP), same hash for same file (cache-friendly). Common CDNs with SRI: jsdelivr.com (shows SRI hash), cdnjs.com (copy SRI button), unpkg.com (generate hash). For self-hosted: generate hash during build, include in HTML templates. This tool generates production-ready SRI snippets.
Browser blocks resource execution and fires error event. Console shows: "Failed to find a valid digest in the 'integrity' attribute for resource 'URL'". Consequences: script does not run (may break page functionality), CSS does not apply (visual issues), onerror event fires (can catch with JavaScript). Common causes: file updated on CDN (new version), typo in hash value, wrong file URL, CORS misconfiguration (missing crossorigin). Debugging: check browser console, verify file content matches hash, regenerate hash, ensure CORS headers present. Fallback strategy: use <script onerror="..."> handler to load local copy if CDN fails. Update hashes when upgrading library versions. This tool helps verify current file matches expected hash.
Integrate into build pipeline for automated hash generation. Methods: webpack-subresource-integrity plugin (Webpack), vite-plugin-sri (Vite), generate with command line: openssl dgst -sha384 -binary file.js | openssl base64 -A, Node.js script with crypto module. Build process: 1) Build assets (minify JS/CSS). 2) Generate SRI hash for each file. 3) Inject into HTML template. 4) Deploy assets and HTML together. Version control: commit hashes with code, update on file changes only. CI/CD: automate hash generation on every deployment. Popular tools handle automatically. This tool useful for: local development, manual verification, one-off hash generation, learning SRI concepts.
SRI only works for external resources (separate file URLs), not inline scripts/styles. Inline scripts have no integrity attribute. External scripts with src attribute pointing to https://cdn.example.com/file.js with integrity attribute work with SRI. For dynamic content: if file changes frequently, SRI problematic (hash changes). Solutions: versioned URLs (lib-v1.2.3.js), build-time hash generation, accept hash updates on deployments. Dynamic loading (JavaScript): fetch with integrity check using the Fetch API. Service workers: verify hashes in SW logic. If content truly dynamic (user-generated, personalized), SRI not applicable - use other security measures (CSP, input sanitization). This tool generates hashes for static resources, the primary SRI use case.
SRI and CSP are complementary security mechanisms. CSP: defines which domains can load resources (script-src, style-src). SRI: verifies resource content has not changed. Together: CSP allows cdn.example.com, SRI verifies specific file hash. Example: CSP header Content-Security-Policy: script-src 'self' https://cdn.example.com, HTML: <script src="https://cdn.example.com/lib.js" integrity="sha384-...">. CSP controls source, SRI controls content. Best practice: use both - CSP prevents unauthorized sources, SRI prevents compromised allowed sources. Modern security: CSP + SRI + HTTPS = layered defense. This tool focuses on SRI hash generation - combine with CSP headers for complete protection.
Browser support: all modern browsers (Chrome 45+, Firefox 43+, Safari 11.1+, Edge 17+). IE 11 doesn't support (ignores integrity attribute). Limitations: HTTPS only (no SRI on HTTP), requires CORS (crossorigin attribute), doesn't work for inline scripts, hash updates needed on file changes, doesn't prevent all attacks (can block if CDN fully compromised). Not a replacement for: code review, dependency scanning, CSP, regular security updates. Best for: third-party CDN resources, static assets, public libraries. Performance: minimal overhead (hash verification is fast). Fallback: older browsers ignore integrity attribute gracefully, still load resource. This tool generates cross-browser compatible SRI hashes following W3C standard.