CSP Generator and Evaluator

A Content-Security-Policy is a response header that tells the browser where a page may load scripts, styles, images, frames and connections from, and which behaviours it allows. Its main job is to limit the damage of cross-site scripting: if an attacker manages to inject a script tag, a good policy stops the browser from running it. A policy that is too loose does nothing, and one that is too strict breaks your site, so this page lets you build one step by step and grade the result.

Building a policy

Start with the Build tab. The first choice is the style: “Own origin + listed hosts” produces a policy that allows resources from your own site plus hosts you name, and “Nonce + strict-dynamic (recommended)” produces the modern pattern in which scripts must carry a per-response random value. Then add the extra script hosts you need, the places the page may connect to with fetch or WebSocket, who may embed your site in a frame, and whether inline styles and data: images are allowed. Each switch changes the directives shown below immediately.

What the default produces

With the defaults the output is default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests. The evaluator gives it grade A, 97 out of 100, across 10 directives. It reports four findings; among them are a low-severity note that 'unsafe-inline' for styles lets injected CSS leak data, a note that script-src 'self' trusts every script on your own origin so a JSONP endpoint or file upload could be abused, and a note that no reporting endpoint is set. None of them is an error, which is why the grade stays high.

Evaluating an existing policy

Switch to the Evaluate tab and paste a header or a meta tag. The page parses it and checks the weaknesses that matter: 'unsafe-inline' and 'unsafe-eval' in script-src, wildcard hosts, scheme-only sources like https:, data: URLs in scripts, public hosts known to serve scripts that defeat host-based policies, and a missing object-src, base-uri or frame-ancestors. A policy using a nonce together with 'strict-dynamic' is graded better than a long host list, because strict-dynamic makes browsers ignore the host sources.

Rolling out safely

Use the Report-Only option first. The browser then logs violations to your report endpoint or console without blocking anything, and you can see which resources the policy would break. Fix those, then switch to enforcing mode. Keep the policy in version control, and send the header on every response, including error pages.

Where to put it

The snippet tabs give the header in the syntax of nginx (add_header), Apache (Header always set), Caddy, Netlify and Cloudflare Pages (_headers), Express, IIS and Vercel. The meta-tag form works for a static site that cannot set headers, with the limits above.

Limits

The page cannot crawl your site, so it does not know what your pages load; a strict policy needs testing in the browser. Its list of risky hosts is not exhaustive. A strong policy is a second line of defence: you still need to encode output and validate input.

Related tools

• CSP Script Hasher computes hashes for inline scripts you cannot move.
• Security Headers Generator and Auditor checks the rest of your headers.
• SRI Hash Generator pins third-party files to an exact hash.
• Mixed Content Scanner finds http:// references that a policy would block.