Content Security Policy Generator
Pick the sources your site really needs and get a ready-to-paste Content-Security-Policy header, meta tag and server config. Generate nonces and script hashes, switch to report-only for safe testing, and see warnings for weak directives as you build.
Last updated:
Import an existing policy
Options
Nonce & hash helpers
—
Your server must create a new random nonce for every response. Use this one for templates and testing.
More directives (child-src, manifest-src, sandbox, Trusted Types, raw directives)
script-src-attr 'none')How to use the Content Security Policy Generator
- Start from a preset (Strict, Basic, or add Google Fonts / Analytics) or import a policy you already use.
- Edit each directive: click the chips to add keywords or type hosts such as
https://cdn.example.com. - Add nonces or hashes for inline scripts instead of allowing 'unsafe-inline'.
- Turn on report-only while testing so violations are reported but nothing is blocked.
- Copy the output for your server (Nginx, Apache, _headers, Express) or as a meta tag, deploy it and check the browser console for violations.
CSP directives at a glance
| Directive | Controls | Falls back to default-src? |
|---|---|---|
default-src | Fallback for the fetch directives below | - |
script-src | JavaScript files, inline scripts, event handlers, eval() | Yes |
style-src | Stylesheets, <style> blocks, style attributes | Yes |
img-src, font-src, media-src | Images, web fonts, audio and video | Yes |
connect-src | fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon | Yes |
frame-src, worker-src | Embedded iframes; Web and Service Workers | Yes (via child-src) |
object-src | <object> and <embed> | Yes |
base-uri | URLs allowed in <base href> | No |
form-action | Form submission targets | No |
frame-ancestors | Which sites may embed this page | No (header only) |
upgrade-insecure-requests | Rewrites http:// subresource URLs to https:// | - |
Source expressions
'self': the page's own origin (same scheme, host and port).'none': nothing at all; it must be the only value.- Hosts:
https://cdn.example.com,*.example.com,https://api.example.com:8443. Prefer full https URLs. - Schemes:
https:,data:,blob:,wss:.data:is fine for images but dangerous in script-src. 'nonce-<base64>': allows elements with a matchingnonceattribute.'sha256-<base64>': allows inline code whose hash matches exactly.'strict-dynamic': trust propagates from a nonced or hashed script to the scripts it loads; host lists are then ignored.'unsafe-inline','unsafe-eval','unsafe-hashes': weaken protection; avoid them in script-src when you can.
A safe way to roll out a CSP
- Start with the Basic or Strict preset and add the third-party services you actually use.
- Deploy it as
Content-Security-Policy-Report-Onlywith a report endpoint and browse every type of page on your site. - Fix or allow each legitimate violation (move inline scripts to files, add nonces, add hosts).
- Switch to the enforcing
Content-Security-Policyheader and keep reporting enabled to catch regressions.
Frequently asked questions
What is a Content Security Policy?
A Content Security Policy (CSP) is an HTTP response header that tells the browser which sources of scripts, styles, images, frames and other content a page may load. Anything not on the list is blocked, which makes cross-site scripting (XSS) and data injection attacks much harder.
Should I use the header or the meta tag?
Use the HTTP header whenever you can. The meta tag works for most directives, but browsers ignore frame-ancestors, report-uri, report-to and sandbox in a meta tag, and report-only mode is not available at all. The meta tag also only protects content that comes after it, so it must be at the top of the head.
What is a CSP nonce?
A nonce is a random, single-use value that you add to the policy as 'nonce-abc123' and to each allowed inline script as nonce="abc123". The server must generate a new unpredictable nonce for every response; a fixed nonce gives no protection. Nonces generated here are 128-bit random values for testing or templates.
What does 'strict-dynamic' do?
With 'strict-dynamic', a script that was allowed through a nonce or hash may load further scripts, and host allowlists and 'self' in script-src are ignored by browsers that support CSP Level 3. It is the basis of Google's recommended strict CSP: script-src 'nonce-...' 'strict-dynamic', with https: and 'unsafe-inline' only as fallbacks for older browsers.
How do I test a CSP without breaking my site?
Send it as Content-Security-Policy-Report-Only first. Browsers then report violations in the developer console (and to your report-uri or report-to endpoint) but load everything as usual. When the reports are clean, switch to the enforcing Content-Security-Policy header.
Why is 'unsafe-inline' a problem?
'unsafe-inline' allows any inline script and event handler on the page, which is exactly what most XSS attacks inject, so it removes most of the protection of CSP. Prefer nonces or hashes. Note that when a nonce or hash is present in script-src, CSP Level 2+ browsers ignore 'unsafe-inline', so it can stay as a fallback for very old browsers.
Does CSP replace X-Frame-Options?
The frame-ancestors directive is the modern replacement for X-Frame-Options and is more flexible (it accepts a list of allowed origins). frame-ancestors 'none' equals DENY and 'self' equals SAMEORIGIN. Many sites send both headers for older browsers.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.