CSP Generator

A Content-Security-Policy header is one of the strongest defenses a site can deploy against cross-site scripting, data injection, and unwanted third-party scripts, but the header's syntax is unforgiving, and one stray quote or missing source can silently break pages or quietly weaken the policy. The CSP Generator turns that chore into a guided, directive-by-directive build. Nine directives are laid out as cards: default-src, script-src, style-src, img-src, font-src, connect-src, media-src, frame-src, and object-src, each with its own enable switch, a preset selector covering 'none', 'self', HTTPS-only, allow-all, and custom-only values, and a textarea for space-separated custom sources. An optional report-uri field appends an endpoint that receives violation reports, and the UI nudges you toward testing with a Content-Security-Policy-Report-Only header before enforcing. The assembled header value updates live as you toggle, with an active-directive count and character length shown underneath, ready to copy or download as csp.txt. For developers building a content security policy header generator workflow into a Next.js, Nginx, or Cloudflare setup, this tool removes the guesswork from getting the syntax right the first time.

1. 1

   Review the live header in the CSP header value box; it updates the moment any control below changes.

2. 2

   In the Directives card, use the switch beside each directive to include or drop it from the policy.

3. 3

   Pick a Preset per directive: None, Same origin, HTTPS only, All, or Custom only.

4. 4

   Add space-separated Custom sources in the textarea, like https://cdn.example.com or 'unsafe-inline'.

5. 5

   Type an endpoint in the report-uri field to receive violation reports, then use Copy or download the result as csp.txt.

• Standing up a CSP for a fresh Next.js or Vercel deployment before any third-party script is added.
• Replacing a wildcard * policy that currently allows any script origin on a legacy site.
• Building a Report-Only policy to inventory which third-party origins your pages actually load.
• Hardening a WordPress, Shopify, or Cloudflare site without hand-editing header syntax.
• Documenting the exact allowed origins for an app review or security questionnaire.
• Teaching web security by toggling directives and watching the assembled header change live.

• Never ship script-src with * combined with 'unsafe-inline' and 'unsafe-eval'; that combination cancels the XSS protection CSP exists to provide.
• Start with Report-Only in production until violation reports confirm nothing legitimate is blocked.
• Keep default-src at 'self' as a fallback so directives you forget inherit the strict default instead of nothing.
• Prefer listing exact third-party origins over wildcards; a compromised subdomain is easier to slip into a wildcard.
• Set object-src to 'none' unless you genuinely still serve Flash or Java plugins, which almost nobody should.
• Route report-uri to an endpoint you own and actually monitor; otherwise violations are silently invisible.

• The per-directive preview on the right of each row shows its exact rendered value, so verify tricky quoting before copying.
• Download the result as csp.txt and version it alongside your server configuration.
• Use the HTTPS only preset on img-src while third-party images vary, then tighten to exact origins as you discover them.
• Leave report-uri empty while drafting, then fill it once the policy is nearly final.