CSP Generator
Build a CSP header from source lists and catch risky combinations before browser enforcement.
Fallback for fetch directives you do not set explicitly.
Scripts, modules, inline-script permissions, nonces and hashes.
Stylesheets and inline-style permissions.
Images, favicons and data/blob sources when needed.
fetch(), XHR, WebSocket and related connections.
Web-font sources.
Frames the page is allowed to load.
Dedicated, shared and service worker script origins.
Audio and video sources.
Plugin-style object/embed content; 'none' is a common baseline.
Where a document base URL may point; no default-src fallback.
Who may embed this page; different from frame-src.
Where forms may submit; no default-src fallback.
Generated CSP Header
Start narrow, then open only what the page really needs
Content Security Policy gives the browser a resource-loading boundary. A strict starting point makes unexpected dependencies visible; widening one directive at a time is easier to reason about than beginning with broad wildcards and trying to tighten them later.
The generated header is not a security verdict. CSP is defense in depth beside output encoding, safe DOM APIs, dependency hygiene and application authorization. It can reduce the impact of some injection bugs, but it cannot repair unsafe application code by itself.
A source list is not a place to paste another directive
Each field accepts only the value that comes after a directive name. For example, enter 'self' https://cdn.example.com in script-src, not script-src 'self';. Semicolons and line breaks are stripped to prevent one field from spilling into another, and the warning list calls out directive names that appear inside a source field.
Three directives that are often confused
Controls frames that your page loads.
Controls which parent pages may embed your page. It does not fall back to default-src and is ignored when CSP is delivered only through a meta element.
Limits form submission targets. It also does not inherit a missing value from default-src.
Nonces and hashes change the inline-script story
A nonce or hash can authorize specific inline script without opening every inline script through 'unsafe-inline'. A nonce must be unpredictable and newly generated for each response; a static nonce copied into a permanent policy defeats the point. Hash sources must match the exact bytes of the inline script or style the browser sees.
If you use 'strict-dynamic', browser behavior around host allowlists and trusted script loading becomes more subtle. Treat that as an application design choice, not just another token to add to a list.
Report-Only catches breakage before enforcement
On an existing application, first sending the same policy as Content-Security-Policy-Report-Only can reveal blocked scripts, styles, frames and connections without immediately breaking the page. Reports can be noisy and browser coverage varies, so combine them with DevTools and real application testing before switching to enforcement.
What this builder deliberately leaves out
CSP Level 3 includes more directives than fit a focused source-list builder, including script-src-elem, script-src-attr, style-src-elem, style-src-attr, manifest-src, child-src, sandbox, reporting directives and source-less directives such as upgrade-insecure-requests. When one of those matters, add it deliberately in your server configuration rather than assuming default-src covers it.
Read the specification when browser behavior is surprising
The W3C Content Security Policy Level 3 specification defines directive fallback, source matching, inline checks and frame-ancestor behavior. MDN's CSP guide is a more approachable companion for deployment examples and nonce/hash patterns.
W3C — Content Security Policy Level 3·MDN — Content Security Policy guide