CSP Hashes and Nonces
Content Security Policy provides two powerful mechanisms to allow specific inline scripts and styles while maintaining security: hashes and nonces. These mechanisms are more secure alternatives to using'unsafe-inline'.
Hashes (SHA-256, SHA-384, SHA-512)
A hash is a cryptographic fingerprint of a piece of data (in this case, the content of an inline script or style). You use a hashing algorithm to generate a unique, fixed-size string that represents the content.How Hashes Work
Calculate the hash of your inline script or style block content (not the entire tag)
Include the hash in your CSP header, prefixed with the algorithm used (e.g., sha256-)
Browser verifies the hash of encountered inline content against the CSP header
Example with Hashes
Example of using hashes with CSP
<!-- Original inline script -->
<script>
console.log('Hello from inline script!');
</script>
<!-- CSP Header -->
Content-Security-Policy: script-src 'sha256-jzgBGA4UWFFmpC6hS8HmB1FfsW5gPDyFF8R8gAAlR8=' 'unsafe-hashes';Important Note
The 'unsafe-hashes' keyword is required when using hashes for inline scripts. This tells the browser that inline scripts are allowed if their hash matches.
Calculate CSP Hash
Nonces (Number Used Once)
A nonce is a cryptographically strong random value generated by the server for each HTTP request. It's a "number used once," meaning it should be unique for every page load.How Nonces Work
Server generates a strong, unpredictable random value (the nonce)
Include nonce in CSP header, prefixed with 'nonce-'
Add the same nonce value as an attribute to every script/style tag you want to allow
Example with Nonces
Example of using nonces with CSP
<!-- CSP Header -->
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa' 'strict-dynamic';
<!-- HTML -->
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa" src="main.js"></script>
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
console.log("Inline script with nonce");
</script>Comparison
Hashes are calculated from content, while nonces are random values generated per request
Hashes require updates on content changes, while nonces are generated server-side for each request
Hashes require 'unsafe-hashes', while nonces work well with 'strict-dynamic'
Hashes are better for static content, while nonces excel with dynamic content
Best Practices
'strict-dynamic' Use nonces for modern web applications with server-side rendering
'sha256-<hash>' Use hashes for small, static inline scripts/styles
'unsafe-inline' Avoid 'unsafe-inline' when possible
Additional Information
- The
'strict-dynamic'keyword is commonly used with nonces to allow dynamically loaded scripts - Hashes must be recalculated whenever the inline content changes
- Nonces must be unique for each request and handled securely
- Both mechanisms are more secure than using
'unsafe-inline'
Related Resources
External Articles
- MDN Web Docs: script-src
- OWASP: Content Security Policy Cheat Sheet
- Google Web Fundamentals: Content Security Policy
Related Documentation Sections
Conclusion
Nonces are generally the preferred approach for modern web applications due to better security and easier management of dynamic content. Hashes are useful for specific situations where nonces aren't feasible or when you need granular control over allowed inline code. Always prioritize security best practices and choose the method that best fits your specific needs and constraints.