CSP Generator
Build a Content Security Policy header visually. Fill in the sources for each directive and get a ready-to-use header value.
CSP Generator
Build a Content Security Policy header visually.
What is a Content Security Policy?
A Content Security Policy (CSP) is an HTTP response header that tells the browser which sources it is allowed to load resources from. It is the most powerful browser-enforced defense against Cross-Site Scripting (XSS) — the attack where an adversary injects malicious scripts into a web page viewed by other users.
Without CSP, a browser will load and execute any script it finds in a page — whether it was put there by the developer or injected by an attacker through a form field, URL parameter, or stored in a database. With CSP, the browser only executes scripts that come from sources explicitly listed in the policy.
CSP is defined in the W3C Content Security Policy specification and is supported in all modern browsers. It can be delivered as an HTTP header (Content-Security-Policy) or as an HTML meta tag (with limitations).
Understanding XSS — why CSP matters
Cross-Site Scripting (XSS) is consistently ranked in the OWASP Top 10 most critical web application vulnerabilities. It occurs when an attacker manages to inject JavaScript into a page that other users view. That JavaScript then runs in the victim's browser with full access to the page — it can steal session cookies, perform actions on behalf of the user, log keystrokes, redirect to phishing pages, or exfiltrate data.
The three types of XSS are:
- Stored XSS — malicious script is saved to a database (e.g., in a comment or profile field) and served to every user who views it.
- Reflected XSS — malicious script is embedded in a URL, reflected back in the response, and executed when the victim clicks the link.
- DOM-based XSS — the vulnerability is in client-side JavaScript that reads attacker-controlled data (URL hash, postMessage) and writes it to the DOM unsafely.
A well-configured CSP stops all three by refusing to execute scripts that don't come from trusted sources.
CSP directives explained
Controls which sources JavaScript can be loaded from. The most critical directive. 'self' allows scripts from the same origin. 'unsafe-inline' allows inline scripts — avoid this if possible. 'nonce-{random}' allows specific inline scripts with a matching nonce attribute.
Controls CSS source loading. 'unsafe-inline' is commonly needed for inline styles but weakens protection. Use nonces or hashes for specific inline styles instead where possible.
Controls image sources. data: allows base64-embedded images. https: allows all HTTPS image sources.
Controls which URLs can be loaded using fetch, XMLHttpRequest, WebSocket, and EventSource. Critical for SPAs that call APIs — list every API endpoint your app connects to.
frame-src controls which sources your page can embed in iframes. frame-ancestors controls which origins can embed your page in an iframe — this replaces X-Frame-Options.
Common CSP mistakes
- Using
'unsafe-inline'inscript-src— this defeats most of the XSS protection. - Using
'unsafe-eval'— allows eval() and related functions that can turn DOM XSS into script injection. - Using wildcard sources like
https:inscript-src— this allows scripts from any HTTPS source, which is nearly as permissive as no CSP at all. - Forgetting
default-src— without a fallback directive, unspecified resource types fall through with no restriction. - Not testing with
Content-Security-Policy-Report-Onlyfirst — always deploy in report-only mode and review violations before enforcing.