CSP Builder

CSP is a server-sent header (Content-Security-Policy or as a <meta http-equiv> tag) that tells the browser which sources are allowed for scripts, styles, images, frames, fonts, connections, and several other resource types. When the browser encounters something not on the allowlist, it refuses to load it and posts a violation report if a report-uri is configured.

The XSS mitigation is specifically: even if an attacker injects <script>alert(1)</script> into your HTML, the browser will not run it unless your CSP allows inline scripts ('unsafe-inline') or the attacker can inject from one of your allowlisted hosts. CSP turns "any injection is RCE" into "injection is harmless unless you also allow inline".

• script-src — controls JavaScript sources. The XSS-prevention workhorse. If unsafe-inline is in this directive, you have no CSP-based XSS protection.
• default-src — fallback for any directive you do not explicitly set. Start strict (default-src 'self') and override per-type.
• frame-ancestors — prevents your site from being framed by other sites. Modern replacement for X-Frame-Options.
• object-src — controls <object>, <embed>. Should be 'none' unless you actually use them. Plugin attack surface lives here.
• base-uri — prevents attackers from changing the <base> tag and rewriting all relative URLs. base-uri 'self' or 'none'.
• form-action — controls where forms can submit. Prevents form-action injection attacks.
• connect-src — controls fetch/XHR/WebSocket targets. Important for preventing data exfiltration via injected JS that reaches a controlled endpoint.
• img-src — usually permissive. data: is common (for inline icons) but enables some attacks. https: only is safer than wildcard.
• style-src — CSS injection is less critical than script injection but can still exfiltrate data via background-image: url() + selectors.

• Nonce-based — script-src 'nonce-RANDOM'. Each page generates a fresh nonce; only inline scripts with matching nonce="RANDOM" run. Strong protection, requires server-side rendering.
• Hash-based — script-src 'sha256-...'. Allow specific inline scripts by their hash. Works for static inline scripts; brittle if scripts change.
• strict-dynamic — script-src 'strict-dynamic' 'nonce-RANDOM'. The trusted scripts can themselves load other scripts dynamically without each new one needing nonce. Modern best practice for SPAs.
• report-only — Content-Security-Policy-Report-Only: send violation reports but do not block. Use during rollout to find what would break.
• unsafe-inline — gives up most of CSP's XSS protection. Use only as a transitional step. Pair with hash or nonce to migrate off.
• unsafe-eval — allows eval(), new Function(), setTimeout("string"). Some frameworks (older Vue, AngularJS) require it. Remove if possible.

• You are adding CSP to an existing site for the first time. Start in report-only mode for a week, fix violations, then enforce.
• You inherited a permissive CSP (default-src *) and want to tighten it. Generate a strict baseline, identify legitimate exceptions one at a time.
• You are integrating a new third party (Intercom, Mixpanel, Stripe Elements) and need the host names to add to script-src and connect-src.
• You are preparing for an audit (PCI-DSS, ISO 27001) that requires CSP enforcement on customer-facing pages.

• It will not test your live site. Use the report-only header in production for a week to discover real violations — synthetic testing misses dynamically-injected scripts from CMS embeds and customer JavaScript.
• It will not handle the unsafe-inline-to-nonce migration. That requires server-side template changes to emit the nonce attribute on every inline script and style.
• It will not enforce CSP at the browser. The header is a hint; older browsers (and any non-browser client) ignore it. CSP is defense-in-depth, not a replacement for output encoding or input validation.