Content Security Policy Generator
Build a Content-Security-Policy with directive pickers and presets, output it as a header, meta tag, nginx or Apache line, and analyze an existing policy.
How to use CSP Generator
- 1Pick a preset, or tick sources for each directive and add any hosts you use, such as https://cdn.example.com.
- 2Choose the output format, then read the warnings and fix anything you do not intend.
- 3Copy the line into your server or page. Or switch to Analyze and paste the policy you already run.
What makes it better
- Build and Analyze modes on every page; Try example loads a policy into the builder
- Directive pickers for default-src, script-src, style-src, img-src, connect-src, frame-ancestors, base-uri, form-action, object-src and more
- Output as HTTP header, meta tag, nginx add_header or Apache Header, with notes on what each format cannot do
- Warnings for *, unsafe-inline, unsafe-eval, data: in script-src and a missing object-src or base-uri
- Analyzer reports unknown directives and bad quoting such as self without quotes, with line and column
About CSP Generator
CSP Generator builds a Content-Security-Policy from directive pickers for scripts, styles, images, fonts, connections, frames and more, with presets for a strict nonce-based policy, a basic same-origin policy, report-only trials and API responses. The result is shown as an HTTP header, a meta tag, an nginx add_header line or an Apache Header line, with warnings for risky choices. The Analyze mode parses a policy you paste and lists every directive, syntax mistake and weakness with its line and column.
Common uses
- Draft a first policy for a site and trial it as report-only before enforcing it.
- Move a site from unsafe-inline to a nonce-based policy and check what is still weak.
- Review a policy copied from a server config or a security scan for typos and missing directives.
- Produce the exact nginx or Apache line for a deployment ticket.
Example
Input
default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; upgrade-insecure-requests
Result
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; upgrade-insecure-requests
Good to know
- This page cannot see which scripts, styles or images your site really loads, and it never fetches your site. A policy that looks fine here can still break a page, so test it in report-only mode and watch the violation reports before enforcing it.
- Nonce and hash values are placeholders. A nonce must be new and random for every response and be added to each script tag, and a hash must be the base64 SHA digest of that exact inline content; neither can be generated statically here.
- A meta tag ignores frame-ancestors, report-uri, report-to and sandbox and cannot be report-only, so use an HTTP header for those. Warnings are guidance, not a complete security audit.
CSP Generator FAQ
What is a Content-Security-Policy and what does it stop?
It is a response header that lists where a page may load scripts, styles, images and frames from. A tight policy limits the damage of cross-site scripting, because injected script from an unlisted source or without a nonce will not run.
Why is unsafe-inline flagged as a risk?
It allows every inline script and onclick-style handler, which is exactly what an injection attack supplies. Replace it with per-response nonces or hashes; browsers that understand those ignore unsafe-inline, so it can stay as a legacy fallback.
Should I start with Content-Security-Policy-Report-Only?
Yes for an existing site. Report-only logs what would have been blocked without breaking pages. Add a report-uri or report-to endpoint, fix the violations you see, then switch the header name to enforce the policy.
Which directives are not covered by default-src?
base-uri, form-action and frame-ancestors never fall back to default-src, so they need their own lines. The same applies to report-uri, sandbox and upgrade-insecure-requests, which are not fetch directives at all.
Can I set a CSP with a meta tag instead of a header?
Partly. A meta tag works for most fetch directives if it appears early in head, but it ignores frame-ancestors, reporting directives and sandbox, and it cannot be report-only. Use the HTTP header whenever you can.
Does the policy I build get uploaded?
No. The builder and the analyzer run in your browser, and they only transform the text you enter, so your policy and host names stay on your device.