CSP Generator
Build a Content-Security-Policy header without memorising the syntax. Pick sources directive by directive, start from a preset, see what is weak, and copy the result for your server, a meta tag or a _headers file. Everything runs in your browser.
Build your policy
Start from a preset, then tick the sources each directive needs and add your own hosts. The policy updates as you go.
The policy is built in your browser. Nothing you choose or paste is sent to a server, logged or saved.
A Content-Security-Policy tells the browser exactly where a page may load scripts, styles, images, fonts and frames from. Anything else is blocked, which turns most cross-site scripting bugs from a breach into a console error. The catch is the syntax: one missing quote or source and the site breaks. This generator writes it for you and flags the settings that quietly undo the protection.
Key benefits
Common use cases
How to use it
- 1.Pick a preset. Start from Strict starter, then add Google Analytics 4, Google Fonts or the other presets your site uses. Or import your current policy.
- 2.Adjust each directive. Tick the keywords each one needs and type extra hosts, such as
https://cdn.example.com, in the box under it. - 3.Read the policy check. Fix anything marked ✗ and decide on anything marked ⚠. Each message says why it matters.
- 4.Deploy in report-only first. Turn on Report-only mode, copy the snippet for your server, and watch the browser console for a few days before you enforce it.
The directives that matter most
Start strict with default-src and loosen only what a real feature needs. These six settings carry most of the protection.
'unsafe-inline'; allow inline code with a nonce or a hash, and list only the script hosts you really use.Key features
- 14 directives, each with the keywords that apply to it and free-form hosts
- Presets for a strict starting point, Google Analytics 4, Google Fonts, YouTube and Stripe
- Imports an existing header so you can review or extend it
- Live policy check for unsafe-inline, unsafe-eval, https:, data:, wildcards and missing directives
- Report-only mode, upgrade-insecure-requests and report-uri
- Output for an HTTP header, a meta tag, Nginx, Apache and _headers files
- Runs in your browser; nothing is uploaded
A CSP is a second line of defence
CSP limits the damage when an injection bug slips through; it does not replace escaping output and validating input. A policy that allows 'unsafe-inline' scripts, or any HTTPS host, looks reassuring and stops very little, so treat the warnings here as the real work.
Roll a new policy out gently: send it as Report-Only, fix what breaks, then enforce it. After deploying, our security headers checker confirms the header is actually being sent, alongside HSTS and the rest. The security headers guide explains how CSP fits with them.
Frequently asked questions
What is a Content-Security-Policy?⌄
A Content-Security-Policy is an HTTP response header that lists where a page may load scripts, styles, images, fonts, frames and other resources from. The browser blocks everything else. Its main job is to stop cross-site scripting: even if an attacker injects a script tag, the browser refuses to run it.
Should I use a header or a meta tag?⌄
Use the HTTP header whenever you can. A meta tag works for most directives, but it cannot carry frame-ancestors, report-uri or report-only mode, and it only applies to content after the tag. The meta tag is a fallback for hosting where you cannot set headers.
Why is 'unsafe-inline' bad in script-src?⌄
Because it lets any inline script run, including one an attacker injects, which is exactly what CSP exists to prevent. If you need inline scripts, give each one a nonce that changes on every response, or allow its SHA-256 hash. 'unsafe-inline' in style-src is much less risky and often tolerated.
Will a CSP break my site?⌄
A strict policy usually blocks something the first time: an analytics tag, a font, an embed. That is why you should send it as Content-Security-Policy-Report-Only first, watch the browser console or your report endpoint, add the sources you really need, and only then switch to enforcing.
How do I check that my CSP is live?⌄
Open the page, then look at the response headers in your browser developer tools, or run the domain through a security headers checker. Violations appear in the browser console with the directive and the blocked URL, which tells you exactly what to add.