Is my CSP data sent to a server?

No. All CSP header generation runs 100% in your browser. Your domain names and policy configuration never leave your device.

What is a Content Security Policy (CSP)?

A Content Security Policy is an HTTP response header that tells browsers which sources of content (scripts, styles, images, fonts, etc.) are allowed to load on your page. It is the primary defense against Cross-Site Scripting (XSS) attacks.

What does "unsafe-inline" mean and why should I avoid it?

"unsafe-inline" allows inline scripts and styles — tags without src, onclick handlers, and style attributes. This defeats most of the XSS protection CSP provides, since attackers can inject inline scripts. Use nonces or hashes instead to allow specific inline scripts.

A nonce (number used once) is a random value generated per request and added to both the CSP header (script-src 'nonce-abc123') and the script tag ( ). Only scripts with the matching nonce execute. This allows specific inline scripts while blocking injected ones.

What is the difference between Content-Security-Policy and Content-Security-Policy-Report-Only?

Content-Security-Policy enforces the policy — violations are blocked. Content-Security-Policy-Report-Only only reports violations (to a report-uri endpoint) without blocking anything. Use Report-Only to test a new policy before enforcing it.

CSP Header Builder

Visual builder for the Content-Security-Policy HTTP header. Toggle directives, drop in sources, and copy the result.

Presets

Report-Only— emit as Content-Security-Policy-Report-Only.Delivered via <meta>— enables warnings for directives that only work in headers.

Fetch directives

default-srcFallback for fetch directives that have not been declared explicitly.

'self'

Document directives

Behavior

Reporting

default-src 'self'

LintNo issues

No issues detected. Policy looks reasonable.

About the CSP Builder

Content Security Policy is one of the most effective browser security mechanisms — and one of the most complex to configure correctly. A policy that's too strict breaks your site; one that's too permissive provides no protection. This builder lets you configure CSP directives visually, validates your policy for common mistakes, and generates the correct header value ready to add to your server configuration.

Key CSP directives

script-src

Controls which scripts can execute. The most important directive for XSS prevention. Avoid 'unsafe-inline' — use nonces or hashes instead.

default-src

Fallback for all resource types not explicitly specified. Set to 'self' as a baseline, then add specific directives for exceptions.

connect-src

Controls which URLs can be loaded via fetch, XHR, WebSocket, and EventSource. Add your API domains here to allow AJAX calls.

frame-ancestors

Controls which pages can embed your page in an iframe. Set to 'none' to prevent clickjacking. Supersedes the X-Frame-Options header.

Deployment strategy

Start with Content-Security-Policy-Report-Only to audit violations without breaking anything
Add a report-uri or report-to endpoint to collect violation reports
Fix violations iteratively, then switch to enforcing mode
Use nonces for inline scripts rather than 'unsafe-inline'

Pipeline

Nginx Config Builder — add the generated CSP header to your Nginx server block.
HTTP Codes — understand the responses your CSP violations generate.

Frequently asked

Is my CSP data sent to a server?: No. All CSP header generation runs 100% in your browser. Your domain names and policy configuration never leave your device.
What is a Content Security Policy (CSP)?: A Content Security Policy is an HTTP response header that tells browsers which sources of content (scripts, styles, images, fonts, etc.) are allowed to load on your page. It is the primary defense against Cross-Site Scripting (XSS) attacks.
What does "unsafe-inline" mean and why should I avoid it?: "unsafe-inline" allows inline scripts and styles — <script> tags without src, onclick handlers, and style attributes. This defeats most of the XSS protection CSP provides, since attackers can inject inline scripts. Use nonces or hashes instead to allow specific inline scripts.
What is a CSP nonce?: A nonce (number used once) is a random value generated per request and added to both the CSP header (script-src 'nonce-abc123') and the script tag (<script nonce="abc123">). Only scripts with the matching nonce execute. This allows specific inline scripts while blocking injected ones.
What is the difference between Content-Security-Policy and Content-Security-Policy-Report-Only?: Content-Security-Policy enforces the policy — violations are blocked. Content-Security-Policy-Report-Only only reports violations (to a report-uri endpoint) without blocking anything. Use Report-Only to test a new policy before enforcing it.