Free Content-Security-Policy Generator – Build a CSP Header

What a Content-Security-Policy Does and How to Build One Safely

A Content-Security-Policy, or CSP, is an HTTP response header that tells the browser which sources of scripts, styles, images, fonts, and other resources your page is allowed to load and execute. It is one of the strongest defenses against cross-site scripting (XSS), because even if an attacker manages to inject a malicious script tag, a well-configured CSP stops the browser from running it. This generator builds that policy directive by directive, explaining what each one controls and what breaks if you get it wrong, so front-end developers, security engineers, and site owners can produce a working policy without memorizing the entire specification. A CSP is a semicolon-separated list of directives, each naming a resource type and the sources allowed for it. default-src is the fallback for anything not explicitly set; script-src controls JavaScript; style-src controls CSS; img-src, font-src, connect-src, media-src, frame-src, and others cover their respective resource types; and frame-ancestors controls who may embed your page in an iframe, the modern anti-clickjacking control. Sources are expressed as tokens like 'self' (same origin), 'none' (block everything), specific https hosts, or the risky 'unsafe-inline' and 'unsafe-eval'. The tool assembles your selections into three outputs: the enforced Content-Security-Policy header, a Content-Security-Policy-Report-Only variant that logs violations without blocking, and an equivalent meta tag, noting that frame-ancestors and report-uri are ignored inside a meta tag. Start from the strict preset and you get default-src 'self' with object-src 'none', base-uri 'self', form-action 'self', and frame-ancestors 'self' — a policy that only allows resources from your own origin. If you then add 'unsafe-inline' to script-src to make a legacy inline script work, the tool immediately shows a warning banner explaining that 'unsafe-inline' lets any injected inline script run, which largely defeats the XSS protection CSP is meant to provide. The recommended alternative is the nonce starter preset, which produces script-src with a generated 'nonce-<value>' plus 'strict-dynamic', so only scripts carrying that exact per-request nonce execute. The tool generates a sample nonce locally for preview, while making clear that a real nonce must be freshly minted on the server for every single request. A developer hardening a new site pastes the strict preset, then adds only the specific CDN and analytics hosts their app genuinely needs, watching the warning stay quiet as long as no unsafe token is enabled. A team running Google Analytics and AdSense uses the dedicated preset that pre-fills the typical Google domains, treating it as a starting point they verify against their own account rather than a guaranteed-complete list. A security engineer rolling out CSP to a large existing site first deploys the report-only variant with a report-uri endpoint, collects violation reports for a week to see exactly what would break, and only then switches to the enforced header — the standard, low-risk way to adopt CSP without taking a live site down. The pitfall that trips people up most is reaching for 'unsafe-inline' the moment something stops working, which quietly removes most of the protection; the correct fix is almost always a nonce or a hash for the specific inline script, and the tool nudges you toward that. A second gotcha is expecting a meta-tag CSP to do everything a header does — frame-ancestors, report-uri, and sandbox simply have no effect in a meta tag, so if your policy needs any of those you must use the real HTTP header. This tool builds the policy text only; a production nonce has to be generated server-side per request and injected into both the header and the matching script tag, since a reused or client-generated nonce provides no real protection. Every policy is assembled locally in your browser, and nothing you configure is sent anywhere.

🔥 Trending Tools