How to Generate a Content Security Policy Header

Content Security Policy is one of the most effective defenses against cross-site scripting (XSS) and data injection attacks, but writing a correct policy by hand is tedious and error-prone. The CSP header generator walks you through each directive so you can build a policy that protects your site without breaking its functionality.

Why CSP matters

Without a Content Security Policy, browsers will load and execute any resource a page references — scripts from unknown domains, inline event handlers injected through user input, stylesheets from compromised CDNs. CSP changes the default to deny and forces you to explicitly whitelist every source of content. When a script tries to execute that is not covered by your policy, the browser blocks it and optionally reports the violation.

The policy is built from directives, each controlling a specific resource type. script-src governs JavaScript execution, style-src controls CSS, img-src covers images, and connect-src restricts where fetch() and XMLHttpRequest can reach. The default-src directive acts as a fallback for any resource type you don’t explicitly configure.

Nonces vs hashes

For inline scripts and styles, you have two options beyond the unsafe 'unsafe-inline' keyword. Nonces are random, single-use tokens that your server generates per request and injects into both the CSP header and the <script nonce="..."> attribute. They are ideal for dynamic applications where inline scripts change between pages. Hashes are SHA-256/384/512 digests of the exact script content, specified as 'sha256-base64encodedHash' in the directive. Hashes work well when your inline scripts are static and rarely change, since any edit to the script body invalidates the hash.

Tips and best practices

• Start with Content-Security-Policy-Report-Only. This header logs violations without blocking anything, letting you identify what your policy would break before you enforce it.
• Avoid 'unsafe-inline' and 'unsafe-eval'. These directives effectively disable CSP’s XSS protection for scripts. Use nonces or hashes instead for any inline scripts you control.
• Be specific with source origins. Instead of whitelisting an entire CDN domain like *.cloudflare.com, whitelist the exact hostname: cdnjs.cloudflare.com. Broader rules increase attack surface.
• Set up violation reporting. Use the report-uri or report-to directive to send violation reports to a logging endpoint. This tells you when legitimate resources are blocked and when actual attacks are being stopped.
• Review your policy after adding third-party services. Every new analytics script, chat widget, or font provider needs its domains added to the appropriate directives. A policy that was complete last month may be blocking new integrations today.

Common issues

• Everything breaks after enabling CSP. This usually means inline scripts or styles are being blocked. Check the browser console for violation messages — they tell you exactly which directive blocked which resource. Add nonces or hashes for legitimate inline code.
• Violation reports flooding your endpoint. Browser extensions inject scripts that trigger CSP violations on your page. Filter reports by blocked-uri to separate extension noise from real issues. URIs starting with chrome-extension:// or moz-extension:// are safe to ignore.
• Policy works in Chrome but fails in Safari. CSP support varies slightly across browsers. Safari was late to support some Level 3 directives like worker-src. Test in all target browsers and use fallback directives where needed.