CSP Builder & Linter

Overview

The CSP builder and linter helps you assemble a Content Security Policy from sensible defaults and then audits the result for the common pitfalls — unsafe-inline, missing default-src, dangling reports, overly broad wildcards. Toggle the directives you need, paste an existing policy to audit, or do both in one pass.

It is built for front-end engineers tightening browser headers, security teams reviewing third-party tag managers, and anyone debugging a flood of Content-Security-Policy console errors. A CSP linter saves the back-and-forth of testing a policy in DevTools just to discover you forgot to allow 'self' for fonts.

How it works

The tool builds a header value compliant with the W3C Content Security Policy Level 3 specification. Each directive (default-src, script-src, style-src, img-src, connect-src, font-src, frame-src, form-action, frame-ancestors, report-uri, report-to, etc.) takes a list of source expressions: keywords like 'self', 'none', 'strict-dynamic', scheme sources like https: or data:, host sources like *.example.com, plus nonces and hashes for inline scripts. The linter walks the parsed policy and flags rules that materially weaken protection — 'unsafe-inline' without a nonce, missing fallbacks where default-src is absent, * in script-src, and report-only typos.

Examples

Builder output:
default-src 'self'; script-src 'self' https://cdn.example.com 'nonce-r4nd0m';
style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none';

Linter input:  default-src *; script-src 'unsafe-inline' 'unsafe-eval'
Linter output:
  - warn: default-src * allows any origin
  - error: script-src 'unsafe-inline' negates most XSS protection
  - error: script-src 'unsafe-eval' allows new Function()

Linter input:  default-src 'self'; script-src 'self' 'nonce-abc'
Linter output: no critical issues

FAQ

What is the difference between report-only and enforcing CSP?

Content-Security-Policy-Report-Only evaluates the policy and sends violation reports without blocking anything — perfect for rolling out a new CSP. Content-Security-Policy actually blocks violating resources. Start in report-only mode, fix the noise, then flip to enforcing.

Should I use nonces or hashes for inline scripts?

Nonces are simpler if you can regenerate them per request. Hashes are static and great for CDN-cached HTML, but every script edit invalidates the hash. Both are strictly better than 'unsafe-inline'.

Does 'strict-dynamic' replace allowlists?

Largely yes — with 'strict-dynamic', trust propagates from a nonce'd or hashed script to anything it loads, and host allowlists in script-src are ignored. This is the modern CSP approach for SPAs with many third-party scripts.

What about frame-ancestors vs X-Frame-Options?

frame-ancestors is the CSP-native clickjacking protection and supersedes X-Frame-Options in modern browsers. Set both for now if you need to support legacy clients.

Try CSP Builder & Linter