What does 'unsafe-inline' mean and should I use it?

unsafe-inline allows inline JavaScript (in script tags or event handlers) and inline CSS. It significantly weakens your CSP because XSS attacks typically inject inline scripts. Avoid it if possible. Instead, move all scripts to external files, or use nonces (script-src 'nonce-RANDOM') or hashes (script-src 'sha256-HASH') to allow specific inline scripts without opening the policy to all inline code.

What is the difference between default-src and other directives?

default-src is the fallback directive for all resource types that don't have their own directive set. If script-src is not specified, the browser falls back to default-src. It is best practice to set default-src 'none' or default-src 'self' and then explicitly allow only the resource types your site actually loads.

Should I use the CSP header or the meta tag?

The HTTP response header is strongly preferred. The meta tag equivalent is useful when you cannot control server headers (e.g., static hosting), but it has limitations: it cannot block resources that were already fetched before the meta tag was parsed, and it does not support frame-ancestors, sandbox, or report-uri directives.

How do I deploy a CSP without breaking my site?

Use Content-Security-Policy-Report-Only mode first. This sends violation reports to a report-uri endpoint without actually blocking anything. Monitor the reports for 1-2 weeks to identify legitimate sources your policy would block, add them to your policy, then switch from Report-Only to enforcing mode.

Content Security Policy Generator

Build a CSP header visually, analyze an existing policy, or browse the directive reference. Get an A-F strictness grade instantly.

Presets:

Generated CSP

Add directives above to build your CSP.

HTML Meta Tag:

Paste CSP Header Value

CSP Directives Reference

Directive	Controls	Notes
default-src	All resource types (fallback)	Set to 'none' for maximum security, then explicitly allow each type.
script-src	JavaScript sources	Most important directive. Avoid 'unsafe-inline'. Use nonces or hashes.
style-src	CSS stylesheets	Use nonces to allow inline styles. 'unsafe-inline' is common but weaker.
img-src	Image sources	Include 'data:' if you use base64 images. Add CDN domains.
font-src	Web font sources	Add fonts.gstatic.com for Google Fonts.
connect-src	XHR, fetch, WebSocket	Add all API endpoints your app calls.
frame-src	iframe sources	Use 'none' if you don't embed iframes.
media-src	Video and audio	Add media CDN domains for streaming content.
object-src	Plugins (Flash, etc.)	Set to 'none'. Flash is dead; plugins are a major attack vector.
frame-ancestors	Who can embed this page	Replaces X-Frame-Options. Use 'none' to prevent clickjacking.
base-uri	Allowed values for <base>	Prevents base tag injection attacks. Set to 'self'.
form-action	Form submission targets	Limits where forms can submit data. Set to 'self' usually.

Configure directives above to build your CSP header.

How to Build a Content Security Policy

Start with a preset — click Strict, Moderate, or Permissive to load a template policy, then customise it for your site's needs.
Configure each directive — click source value chips (like 'self' or https:) to toggle them on/off. Add custom domains in the text field below each directive.
Copy the output — use "Copy Header" for nginx/Apache/IIS config, or "Copy Meta Tag" for static HTML pages where you can't set response headers.
Analyze mode — paste an existing CSP to parse it, see each directive, flag unsafe values, and get a strictness grade.

What Is a Content Security Policy?

A Content Security Policy (CSP) is an HTTP response header that instructs the browser about which sources of content are permitted to load on a given page. Without a CSP, a successful XSS injection can execute arbitrary JavaScript from any URL. With a strict CSP, even if an attacker injects a <script src="evil.com/payload.js"> tag, the browser will refuse to load it because evil.com is not in the allowed list.

Understanding Strictness Grades

This tool grades CSPs on an A–F scale based on: whether default-src restricts unknown types (A point), whether script-src avoids 'unsafe-inline' and 'unsafe-eval' (A points), whether object-src is set to 'none' (A point), and whether high-risk sources like wildcards or http: are used (penalty points). Grade A means a strict, modern CSP. Grade F means the policy provides little to no XSS protection.

Deploying Without Breaking Your Site

The safest deployment strategy is Report-Only mode: send the header Content-Security-Policy-Report-Only with a report-uri pointing to a collector (such as report-uri.com). The browser will report violations but not block anything. After reviewing reports for a week or two, adjust your policy to allow legitimate sources, then switch to the enforcing Content-Security-Policy header. See the CORS Header Builder to complement your CSP with proper cross-origin resource sharing controls.

Nonces and Hashes vs. unsafe-inline

Modern CSP implementations replace 'unsafe-inline' with per-request nonces or static hashes. A nonce is a cryptographically random value generated by the server for each request: script-src 'nonce-abc123'. Every inline script tag must include nonce="abc123". Since an attacker cannot predict the nonce, injected scripts without the correct nonce will be blocked. Hashes work similarly for static inline scripts: compute a SHA-256 hash of the script content and add 'sha256-HASH' to the directive. Both approaches allow specific inline code while blocking all other inline execution.

Frequently Asked Questions

A CSP is an HTTP response header that tells browsers which content sources are allowed on a page. It is one of the most effective defences against XSS attacks by preventing the browser from executing injected scripts from untrusted sources.

unsafe-inline allows inline JavaScript and CSS. It significantly weakens your CSP because XSS attacks typically inject inline scripts. Avoid it. Instead, move scripts to external files, or use nonces or hashes to allow specific inline code.

default-src is the fallback for all resource types without their own directive. Best practice: set default-src 'none', then explicitly allow only the resource types your site loads.

The HTTP response header is strongly preferred. The meta tag is useful when you can't control server headers, but it has limitations: it cannot block resources already fetched before the meta tag was parsed, and it doesn't support frame-ancestors, sandbox, or report-uri.

Use Content-Security-Policy-Report-Only mode first. This sends violation reports to a report-uri endpoint without blocking anything. Monitor reports for 1-2 weeks, add legitimate sources, then switch to enforcing mode.