🛡️ Content-Security-Policy Builder
Build a Content-Security-Policy header online
About this tool
A Content-Security-Policy (CSP) header tells the browser which sources a page is allowed to load scripts, styles, images, fonts and other resources from. It is one of the most effective defenses against cross-site scripting (XSS) and data-injection attacks — when configured correctly, it blocks unauthorized inline scripts and external domains from running.
This builder lets you compose a CSP directive by directive. Tick a directive, type the allowed sources (space-separated, e.g. 'self' https://cdn.example.com), and the header value is generated live. The Strict preset gives you a hardened baseline (script-src restricted, frame-ancestors none, object-src none); the Basic preset is a lenient starting point.
Example output: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: — paste this as the Content-Security-Policy response header, or inside a <meta http-equiv="Content-Security-Policy"> tag.
FAQ
What is the difference between default-src and the specific *-src directives? ›
default-src is the fallback that applies to any resource type you have not set explicitly. A specific directive like script-src overrides default-src for scripts only. A common pattern is default-src 'self' plus tighter or looser rules per resource type.
Why is 'unsafe-inline' needed for styles but not scripts? ›
Many frameworks and CMSes inject inline <style> tags or style attributes at runtime, so blocking inline styles entirely often breaks layouts. Inline scripts are far more dangerous (they execute code), so the modern approach is nonces, hashes, or 'strict-dynamic' rather than 'unsafe-inline'.
How do I allow inline scripts safely? ›
Use per-request nonces (script-src 'self' 'nonce-RANDOM') and add nonce="RANDOM" to each <script> tag, or use a SRI hash (script-src 'sha256-BASE64HASH'). 'strict-dynamic' lets trusted scripts load further scripts without listing every one.
Should I use the <meta> tag or an HTTP response header? ›
An HTTP response header is preferred because it is applied before the page renders and supports all directives (including frame-ancestors, which a meta tag cannot enforce). Use the meta tag only when you cannot modify server or CDN response headers.
Can I share my policy draft with a teammate? ›
Yes. Click <strong>Share link</strong> next to the header output — it copies a URL that encodes the entire directive configuration (every enabled directive, its sources, and the upgrade-insecure-requests / block-all-mixed-content toggles). Opening that link restores the exact policy so you can keep iterating together.