CSP Builder

A Content Security Policy is a list of directives, each naming where a kind of resource may come from. The difficulty is not writing one; it is that several of the rules that decide what a policy does are applied silently, so a policy can look strict and do nothing, or look permissive and break the site.

The rule most builders miss: **a nonce or a hash makes 'unsafe-inline' be ignored.** CSP Level 3 section 6.7.3.2 discards 'unsafe-inline' entirely whenever the same directive carries a nonce or a hash source. Add a nonce to a policy that was relying on 'unsafe-inline' and every inline script without the nonce stops running, with nothing in the policy text to suggest it. This tool shows the written policy and the effective one side by side whenever they differ, and the project tests confirm the behaviour by serving a page under the policy and watching whether Chrome runs the script, rather than by quoting the specification. 'strict-dynamic' is handled the same way: it discards every host source, every scheme source and 'self' in its directive, which the tool reports by name and count.

**Some directives have no default-src fallback.** frame-ancestors, form-action, base-uri, report-uri and sandbox are not covered by default-src, however strict it is, so leaving them out leaves them unrestricted. Each is labelled in the interface and each is reported when missing, with what it costs: any site can frame the page, an injected form can submit anywhere, an injected base element can redirect every relative URL. **Four directives are ignored in a meta element:** frame-ancestors, report-uri, report-to and sandbox. A builder that hands you a meta tag containing them is handing you something that does less than it says, so choosing meta delivery here flags them as errors, which is exactly what Chrome reports in the console.

**A keyword without its quotes is a host name.** 'self' is the keyword; self is a domain, and a policy containing the second is syntactically valid, allows nothing, and reports no error anywhere. Typing an unquoted keyword into a source box corrects it rather than passing it through, and the difference is measured in the tests: a bare self allows nothing, while the corrected 'self' allows the same-origin script.

A nonce is generated for each build from the platform generator, 128 bits as the specification asks, with the reminder that a server has to produce a new one on every response. Inline scripts and styles can be hashed to sha256, sha384 or sha512 and added directly to a directive, which removes the need for 'unsafe-inline' without needing a nonce at all. The policy comes out as an HTTP header, an nginx add_header with the always flag, an Apache Header always set, an Express call, a Netlify _headers block, and a meta element when meta delivery is chosen. Report-only is a first-class mode with the right header name, and the tool points out that a report-only policy with no report-uri blocks nothing and records nothing.

Four presets are offered. The strict one is the shape the specification itself recommends, a nonce with 'strict-dynamic', which is the only arrangement that survives a page adding scripts at runtime without listing every CDN it might reach. A report-only preset is included because turning a policy straight on is how a site breaks: the way to find out what a real site does is to watch it first.