CSP Header Builder

A Content Security Policy is an HTTP response header that tells browsers which resources (scripts, styles, images, fonts, frames) are allowed to load on your page. CSP prevents cross-site scripting (XSS) attacks by blocking inline scripts and resources from unauthorized domains. Without CSP, an attacker who injects malicious JavaScript can steal user data, session cookies, and credentials. A properly configured CSP reduces XSS risk by 90% or more because even if injection occurs, the browser refuses to execute unauthorized scripts. DevBolt's CSP Builder helps you construct the header visually with directive dropdowns and framework-specific presets.

Start with a restrictive default-src 'self' directive that only allows resources from your own domain, then add specific directives to allowlist trusted sources. Common directives include script-src for JavaScript, style-src for CSS, img-src for images, font-src for fonts, and connect-src for API endpoints. DevBolt's CSP Builder provides a visual interface where you select directives and add allowed sources without memorizing the syntax. Framework presets auto-configure common requirements like Google Fonts and analytics scripts. Test your policy in report-only mode first using Content-Security-Policy-Report-Only to log violations without blocking resources.

The 'unsafe-inline' keyword allows inline scripts and styles to execute, which significantly weakens CSP protection against XSS attacks. With unsafe-inline enabled for script-src, any injected inline script can still run, defeating much of CSP's purpose. Avoid it whenever possible. Instead, use nonces that change on every page load, or hashes for specific inline scripts. For styles, unsafe-inline is more commonly needed because many CSS-in-JS libraries inject inline styles. If you must use unsafe-inline for styles, ensure script-src remains strict. DevBolt's builder warns when you select unsafe-inline and suggests nonce-based alternatives.