CSP policy builder
Draft a Content Security Policy header with editable source lists and an explicit fallback preview.
How it works & useful details
How it works & supported syntax
Build an HTTP header from 10 supported source-list directives and optional upgrade-insecure-requests. Empty fields omit a directive. Supports quoted CSP keywords, schemes, ASCII hosts with optional scheme/port/path and nonce/hash source syntax. No credentials, query strings, fragments or IPv6 hosts. Each field supports 30 expressions and 2,000 characters.
Preview explains default-src fallback for supported fetch directives. base-uri, frame-ancestors and form-action do not inherit it. Report-only does not block resources or configure a report endpoint. This builder does not test resource loading, generate nonces, verify hashes or certify a policy’s effectiveness.
Local workspace
Your input stays in this page. These tools calculate or process text; they do not run commands, start containers, contact servers or change settings on your device.
Previews pause above 20,000 combined characters. Use the action to process the full supported input. Exports contain the complete result within the tool’s stated limits.
About this tool
CSP policy builder drafts a Content-Security-Policy header from editable source lists, with an explicit preview of how the fallback directives resolve. It helps you assemble a policy deliberately instead of copying a header you do not understand.
Directives and sources are combined as text; the tool does not test the policy against a live site. The generated header is ready to paste into your server or meta tag configuration.
How to use it
- Select the directives you want to define, such as script-src and style-src.
- Enter the allowed sources for each directive.
- Review the resolved policy and the fallback behavior it implies.
- Copy the finished header into your configuration.
Worked example
The starter policy produces:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'It allows resources only from your own origin, data: URLs for images, no plugins, no framing by other sites, and form submissions only to your own origin. Report-only mode lets you deploy it and watch for violations in the browser console before enforcing it.
Rolling out a policy safely
- Start in report-only mode. Browse the site, and fix or allow each legitimate resource that shows up as a violation.
- Avoid 'unsafe-inline' for scripts where possible. Nonces or hashes allow specific inline scripts without opening the door to injected ones.
- Remember that base-uri, form-action, and frame-ancestors do not fall back to default-src. Set them explicitly.
- Third-party services such as analytics, ads, maps, and payment widgets need their own origins in script-src, connect-src, img-src, and frame-src. Their documentation usually lists them.
Switch to the enforcing Content-Security-Policy header once the reports are clean. A policy limits the damage of injected content, but it does not replace escaping and input validation.
Frequently asked questions
Does this enforce the policy?
No. It composes the header text; the policy only takes effect when your server sends it and a browser applies it.
What does the fallback preview show?
Directives that are not set fall back to default-src, so the preview shows what each resource type will actually be allowed to load.
Can I start in report-only mode?
Yes. Use the header value with a report-only response header while you observe violations before enforcing it.
Can I use this as a meta tag instead of a header?
Mostly. <meta http-equiv="Content-Security-Policy"> supports most directives, but not frame-ancestors or report-only mode. A response header is the recommended approach.