CSP Header Generator
Assemble a Content-Security-Policy from common directives and source lists, with a strict starter preset and both header and meta output.
Processed locally in your browser — nothing is uploaded.
CSP Header Generator
Fallback for any fetch directive you don't set explicitly.
Where <script> may load from. Avoid 'unsafe-inline' here.
Where stylesheets may load from.
Where images may load from. data: covers inline SVG and base64.
Where webfonts may load from.
Targets allowed for fetch, XHR, WebSocket, and EventSource.
Who may embed this page in a frame. 'none' replaces X-Frame-Options: DENY.
Restricts <base href>, blocking a common injection trick.
Where forms on this page may submit to.
Response header
Content-Security-Policy: default-src 'self'
Meta tag
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
The response header is the better delivery method: frame-ancestors and report-uri are ignored inside a <meta> tag, so they are left out of it above. Test a new policy with Content-Security-Policy-Report-Only first — a wrong policy silently breaks scripts.
About CSP Header Generator
Turn each directive on and pick its sources from the usual keywords — 'self', 'none', 'unsafe-inline', 'unsafe-eval', https:, data: — plus any hosts you type in. The policy string builds as you go, ready to paste into an nginx, Apache, or framework config.
The strict starter preset locks everything to 'self', denies framing, and upgrades insecure requests: a defensible baseline you loosen one directive at a time. Both a response header and a <meta> tag are produced, with the directives that a meta tag cannot express left out of it rather than silently ignored.
Common uses
- Add a first Content-Security-Policy to a site that has none
- Work out the right source list after adding a CDN or analytics script
- Generate the meta-tag form for a static page you cannot set headers on
Example
Input
Strict starter preset
Output
Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self' data:; frame-ancestors 'none'; upgrade-insecure-requests
Limitations
- frame-ancestors and report-uri only work as a real response header — browsers ignore them in a meta tag
- 'unsafe-inline' and 'unsafe-eval' undo most of the XSS protection CSP provides; prefer nonces or hashes where you can
- Roll a new policy out with Content-Security-Policy-Report-Only first — a wrong policy breaks scripts with no visible error
Frequently asked questions
What does a Content-Security-Policy header actually protect against?
Primarily cross-site scripting (XSS): the policy tells the browser which origins scripts, styles, images, and other resources may load from, so injected code from anywhere else is refused. Directives like frame-ancestors also block clickjacking by controlling who may embed your page.
Should I use a CSP meta tag or a response header?
The response header, whenever you control the server. Browsers ignore frame-ancestors and report-uri inside a meta tag, which is why this tool leaves them out of the meta output; the meta form is a fallback for static pages where you cannot set headers.
Why did my site break after adding a CSP header?
The policy is blocking resources it doesn't list — inline scripts, a CDN, an analytics domain — and CSP fails silently apart from console errors. Deploy the same policy as Content-Security-Policy-Report-Only first: violations are reported without blocking anything, so you can fix the source lists safely.
Is 'unsafe-inline' really unsafe?
Largely, yes, in script-src: it allows every inline script to run, including ones an attacker injects, which removes most of the XSS protection CSP exists to provide. Prefer moving scripts to files, or allowing specific inline scripts with nonces or hashes.
Is the policy I build here transmitted anywhere?
No. The header and meta tag are assembled by JavaScript in your browser, and nothing is sent or stored — the domains and security posture of your site are not disclosed to any server.