// build Content Security Policy headers with a visual UI
Build Content Security Policy headers visually. Configure script-src, style-src, img-src, and more with a UI — get the header string, meta tag, and .htaccess output instantly. Free, no signup.
'none'Block all sources'self'Same origin only'unsafe-inline'Allow inline code ⚠'unsafe-eval'Allow eval() ⚠'strict-dynamic'Trust script-loaded scripts'nonce-{base64}'Allow specific inline block'sha256-{hash}'Allow by content hashhttps:Any HTTPS sourcedata:Data URIs (images) ⚠blob:Blob URIs*.example.comSubdomain wildcardhttps://cdn.example.comSpecific originToggle the directives you need — script-src, style-src, img-src, etc. Each directive can be individually configured with source values.
Enter source values as a space-separated list in each directive's input. Use quick-add chips for common values like 'self', 'none', or https:.
Switch output format (HTTP Header, meta tag, .htaccess, Nginx), copy the result, and add it to your server or HTML. Test with Report-Only mode first.
Content Security Policy is a browser security mechanism that restricts what resources a web page can load. A properly configured CSP can eliminate entire classes of attacks:
frame-ancestorsupgrade-insecure-requestsconnect-srcA Content Security Policy is an HTTP response header (or meta tag) that tells browsers which content sources are permitted. The policy is a semicolon-separated list of directive-value pairs. Each directive controls a specific resource type. Browsers enforce the policy and optionally report violations to a reporting endpoint — making CSP one of the most effective defenses against XSS attacks.
When you use Content-Security-Policy-Report-Only instead of Content-Security-Policy, the browser enforces the policy silently — it reports violations to the report-uri endpoint but does not block anything. This lets you deploy a new CSP in production and monitor what it would block before switching to enforcing mode. It is the safest way to roll out a new CSP.
The 'unsafe-inline' source value allows browsers to execute inline <script> tags, inline event handlers, and inline <style> blocks. This completely defeats CSP's XSS protection — an attacker who can inject content into your HTML can inject arbitrary scripts. Instead, use nonces ('nonce-{random}') or hashes ('sha256-{hash}') to allow specific inline blocks while blocking injected ones.
A nonce (number used once) is a random base64 value generated server-side for each request. You add it to the CSP header as 'nonce-abc123' and to each allowed inline script as <script nonce="abc123">. The browser only executes inline scripts with the matching nonce. Since each request uses a new random nonce, an attacker who injects content cannot know the nonce in advance and cannot execute injected scripts.
default-src is the fallback for all resource types that don't have their own explicit directive. If you set default-src 'self', all resource types default to same-origin only. If you also set img-src 'self' data:, images follow the more specific rule. Directives that inherit from default-src include script-src, style-src, img-src, connect-src, font-src, object-src, media-src, and frame-src.
Yes, with limitations. The <meta http-equiv="Content-Security-Policy"> tag works for most directives, but some are ignored in meta tags: frame-ancestors, report-uri, and sandbox. HTTP headers are always preferred because they apply before any page content is parsed. Meta tags are useful for static sites where you cannot set HTTP headers.
Google Fonts loads stylesheets from fonts.googleapis.com and font files from fonts.gstatic.com. Your CSP needs: style-src 'self' https://fonts.googleapis.com and font-src 'self' https://fonts.gstatic.com. The 'self' in style-src may also need 'unsafe-inline' if you have inline styles, or you can move all inline styles to external stylesheets.
Content Security Policy headers are powerful but complex to write by hand. A single typo — a missing apostrophe around 'self', a wrong directive name, a missing semicolon — can leave your site unprotected or break legitimate content loading. This generator provides a visual interface that guarantees syntactically correct output every time.
Never deploy a new CSP directly to production in enforcement mode without testing. The recommended workflow: first, deploy in report-only mode with a reporting endpoint. Collect violation reports for at least a week to identify all the legitimate sources your site loads. Update your policy to allow those sources. Then switch from Content-Security-Policy-Report-Only to Content-Security-Policy in enforcement mode.
The "Strict CSP" pattern recommended by Google uses: default-src 'none' (block everything by default), with explicit allowlists for each resource type, using nonces for inline scripts instead of 'unsafe-inline', and strict-dynamic to allow dynamically loaded scripts. This approach eliminates XSS entirely for pages that implement it correctly, and is used by Google, GitHub, and other high-security sites.