Content Security Policy Generator

Builds Content-Security-Policy headers from a set of declared sources per directive. Output covers default-src, script-src, style-src, img-src, connect-src, font-src, frame-src, base-uri, form-action, frame-ancestors, and object-src. Optional directives like upgrade-insecure-requests and block-all-mixed-content can be appended.

Default posture starts strict ('self' only) and adds explicit allowlists per third-party origin. The strictest practical policy avoids 'unsafe-inline' and 'unsafe-eval' in script-src; CSP Level 3 nonces or hashes replace them.

CSP defends primarily against cross-site scripting (XSS) by restricting which origins can serve executable content. The browser parses the CSP header, applies the rules to all resource loads on the page, and blocks any request that violates the policy. An attacker who injects a script tag pointing to evil.com fails because evil.com is not in the script-src allowlist; an attacker who injects an inline <script> block fails because 'unsafe-inline' is not granted.

Modern strict CSP follows a recipe: nonce-based script-src with strict-dynamic. The server generates a per-response random nonce, includes it in the header (script-src 'nonce-abc123' 'strict-dynamic'), and adds nonce='abc123' to each legitimate inline script tag. The 'strict-dynamic' keyword grants trust transitively — a nonced script can load further scripts without each having a nonce. This handles dynamic module loading without weakening the policy.

A worked example for a marketing site embedding Google Analytics, Stripe Checkout, and a custom script. Strict policy: default-src 'self'; script-src 'nonce-{random}' 'strict-dynamic'; style-src 'self' 'nonce-{random}'; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com https://api.stripe.com; frame-src https://js.stripe.com; base-uri 'self'; form-action 'self'; report-uri /api/csp-report. The nonce values are inserted at template render time. This blocks injected scripts from any origin not nonced by the server.

Deployment carries operational risk. A strict policy applied without rehearsal will break the site by blocking inline scripts the developers forgot about — analytics snippets, A/B testing tags, customer support widgets. The recommended path is Content-Security-Policy-Report-Only first, monitor violations for one to two weeks, address each via either allowlisting or removing the offending script, then flip to enforcement. Reverting a broken CSP requires a deployment; report-only mode logs violations without breaking pages.

Limitations: CSP cannot stop all attacks. Dangling-markup injection, scripts loaded by user-installed extensions, and certain DOM clobbering attacks bypass CSP. CSP also doesn't help with non-script-based attacks (CSRF, clickjacking on its own — though frame-ancestors mitigates clickjacking). It is one layer among several; HTTPS, secure cookies, anti-CSRF tokens, and input validation are necessary complements.