CSP Header Generator

Create a Content Security Policy Header

Use this CSP Header Generator to define which scripts, styles, images, fonts, API connections, frames, and other resources a browser may load. Start with a practical preset, customize the source expressions, and copy a complete Content-Security-Policy or Content-Security-Policy-Report-Only response header. Everything runs locally in your browser.

What does a Content Security Policy do?

A Content Security Policy limits the origins from which a page may load or execute content. A well-tested CSP adds defense in depth against cross-site scripting, malicious third-party resources, unwanted framing, and other injection-related risks. It complements secure output encoding and input validation; it does not replace them.

Which CSP preset should I choose?

Choose Deny by Default when you want a restrictive baseline with each important resource type listed explicitly. Self-Hosted suits sites that load nearly everything from their own origin. Web App adds common allowances for HTTPS APIs, WebSockets, frames, data URLs, and blob workers. Treat every preset as a starting point and remove permissions your application does not need.

How do I add a CDN, API, or WebSocket endpoint?

Add space-separated source expressions to the matching directive. For example, add https://cdn.example.com to script-src, https://api.example.com to connect-src, or wss://socket.example.com for a WebSocket server. Avoid broad scheme sources such as https: when a specific trusted host is sufficient.

Should I use CSP report-only mode first?

Report-only mode is useful when introducing a policy to an existing site because violations are reported without blocking resources. Add an HTTPS reporting endpoint and the generator creates both the report-to directive and its required Reporting-Endpoints response header. It can also include the deprecated report-uri directive as a compatibility fallback for older browsers. Review real traffic and tighten the source lists before switching to the enforcing header. Report-only mode offers visibility, not protection, so do not leave it as the only policy indefinitely.

Why are unsafe-inline and unsafe-eval flagged?

'unsafe-inline' permits inline scripts or styles, while 'unsafe-eval' permits JavaScript APIs that compile strings as code. These permissions can weaken important CSP protections. For scripts, prefer a unique server-generated nonce or a content hash. Test carefully because nonces must be unpredictable and must change with each response.

What do object-src, base-uri, and frame-ancestors protect?

object-src 'none' blocks legacy plug-in content, base-uri limits which URLs a <base> element may use, and frame-ancestors controls which sites may embed the page. These directives do not all fall back to default-src, so defining them explicitly closes gaps that a short policy can leave open.

How do I deploy and test the generated CSP header?

Add the generated line as an HTTP response header in your web server, framework, reverse proxy, or hosting platform. If you use Nginx, the Nginx Redirect Generator can help with related server configuration. Test the policy across every page and user flow, inspect browser developer-console violations, and verify authentication, payments, media, analytics, and embedded content before enforcing it in production.

Can a CSP prevent every XSS vulnerability?

No. CSP is a defense-in-depth control that can reduce the impact of many injection bugs, but the application still needs safe templating, contextual output encoding, trusted dependencies, and careful validation. Use tools such as the JWT Analyzer & Decoder and Regex Tester for adjacent development tasks without treating any single tool as a complete security review.