A CSP hash allows you to whitelist specific inline scripts by their cryptographic hash. Instead of enabling 'unsafe-inline', you compute the SHA-256, SHA-384, or SHA-512 hash of the script's content and add it to your script-src directive. Browsers will then only execute inline scripts whose hash matches one in the policy, effectively blocking XSS.

Nonces are ideal for dynamic scripts where the content changes on every page load (e.g., scripts with session-specific data). The server generates a unique nonce for each response and includes it both in the CSP header and as a nonce attribute on the script tag. Hashes, on the other hand, work best for static inline scripts that rarely change.

A secure CSP should avoid 'unsafe-inline' and 'unsafe-eval', restrict sources to exact origins, define object-src 'none', and consider using 'strict-dynamic' with nonces/hashes. Always include a report-uri or report-to directive to monitor violations. Our evaluator helps identify such misconfigurations.

Add it to the script-src directive like this: script-src 'sha256-xyz...';. If you use 'strict-dynamic', the hash allows the inline script and also enables loading of other scripts dynamically added by that script. Remember to base64-encode the hash (as we output) and include the prefix.

Yes. Paste your complete Content-Security-Policy header value into the evaluator, and click “Evaluate Security”. You'll get a breakdown of each directive and a security score. It highlights dangerous keywords like 'unsafe-inline' and missing directives.