CSP Header Generator

What this tool does

CSP Header Generator builds a Content-Security-Policy header value from the most commonly used directives (default-src, script-src, style-src, img-src, connect-src, frame-ancestors and more), with a quick-reference list of standard source keywords and a warning when potentially unsafe values are entered.

A Content-Security-Policy header is one of the most effective defence-in-depth measures against cross-site scripting (XSS) and data injection, but hand-writing a correct, complete policy string across a dozen possible directives is fiddly and easy to get subtly wrong.

This generator builds the policy from individual, labelled directive fields (default-src, script-src, style-src, img-src and more, each with a plain description of what it controls), combines them into the correct semicolon-separated header syntax, and flags potentially risky values like 'unsafe-inline' as you enter them.

How to use CSP Header Generator

1. Fill in a source list for each directive you want to restrict (e.g. 'self' for script-src).
2. Toggle upgrade-insecure-requests and block-all-mixed-content if needed.
3. Review the warning if a directive contains a potentially unsafe keyword.
4. Copy the Generated policy and add it as your Content-Security-Policy header.

Tips for better results

• Start with default-src 'self' as a baseline, then only add more permissive directives for the specific content types that genuinely need a wider source list, this "deny by default, allow specifically" approach gives the strongest practical protection.
• 'unsafe-inline' and 'unsafe-eval' in script-src significantly weaken XSS protection; they’re sometimes unavoidable for legacy code, but avoid them whenever your code can be restructured to not need them.
• Test a new policy with the Content-Security-Policy-Report-Only header first (same syntax, but only logs violations instead of blocking them) before switching to full enforcement, to catch anything it unexpectedly breaks.
• frame-ancestors is specifically your defence against clickjacking (your page being embedded in a malicious iframe elsewhere), separate from frame-src, which instead controls what your page is allowed to embed.

Common use cases

• Building a Content-Security-Policy header for a new web application from scratch.
• Reviewing and tightening an existing, overly permissive CSP policy.
• Understanding what each CSP directive actually controls before setting it.
• Generating a starting-point policy to test with Content-Security-Policy-Report-Only.

Common mistakes to avoid

• Setting script-src to 'unsafe-inline' or 'unsafe-eval' as a default convenience rather than a last resort; both significantly reduce CSP’s real protection against script injection.
• Deploying a new policy directly in enforcing mode without first testing it as Content-Security-Policy-Report-Only, risking breaking legitimate functionality that depends on a source you forgot to allow.
• Confusing frame-src (what your page can embed) with frame-ancestors (who can embed your page); they control opposite directions of framing and are easy to mix up.