Free Tool - No Signup Required

CSP Generator

Build a Content-Security-Policy directive by directive, with a live preview and a safe Report-Only rollout. The strongest defence against cross-site scripting.

Need the other security headers too? HSTS, X-Frame-Options, Permissions-Policy and more — use the full generator.

Build your policy

default-src
script-src
style-src
img-src
connect-src
frame-ancestors

Optional. Where browsers POST a JSON report whenever the policy is violated.

Resulting policy

default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; upgrade-insecure-requests

Your Content-Security-Policy

Header

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; upgrade-insecure-requests

Server snippet

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; upgrade-insecure-requests" always;

Understanding CSP

What it is. A Content-Security-Policy is an allowlist you send with every page. It tells the browser exactly which origins may supply scripts, styles, images, fonts and frames. Anything not allowlisted is blocked — so even if an attacker manages to inject a malicious <script>, the browser simply refuses to run it.

Directives. A policy is built from directives. default-src is the catch-all fallback; more specific ones like script-src and img-src override it for that content type. Each lists sources: the keyword 'self' for your own origin, explicit hosts like cdn.example.com, or schemes like https:.

Roll out safely. A strict CSP can block resources you actually need. Deploy it in Report-Only mode first: the browser reports violations to your report-uri but blocks nothing. Watch real traffic, allowlist the legitimate sources, then switch to enforcing.

Nonces over unsafe-inline. Inline scripts are convenient but dangerous under CSP. Rather than open the door with 'unsafe-inline', generate a fresh random nonce on the server for each request, put it in the policy as 'nonce-…', and add the same value to each trusted inline tag. Only matching scripts run.

Frequently Asked Questions

What is a Content-Security-Policy?
A Content-Security-Policy (CSP) is an HTTP header that tells the browser exactly which sources it is allowed to load — scripts, styles, images, fonts, frames and more. Anything not on the list is blocked. It is the single most effective defence against cross-site scripting (XSS), because even if an attacker injects a script tag, the browser refuses to run it.
How does a CSP work?
A CSP is made of directives. Each directive (like script-src or img-src) lists the allowed sources for one type of content. default-src is the fallback for anything you do not list explicitly. Sources can be keywords like 'self' (your own origin), specific hostnames like cdn.example.com, or schemes like https:.
What is Report-Only mode and why use it?
The Content-Security-Policy-Report-Only header makes the browser watch for violations and report them, but never block anything. It is the safe way to roll out a CSP: deploy it Report-Only first, collect the violation reports from real traffic, fix or allowlist the legitimate ones, and only then switch to the enforcing Content-Security-Policy header.
What is a CSP nonce?
A nonce is a random value your server generates fresh for every page load and adds both to the CSP (as 'nonce-abc123') and to each trusted inline script tag. The browser only runs inline scripts whose nonce matches, so attacker-injected scripts are blocked. Nonces let you keep some inline scripts without resorting to the dangerous 'unsafe-inline'. Replace the {NONCE} placeholder server-side on every request.
Should I use 'unsafe-inline' or 'unsafe-eval'?
Avoid them if you can. 'unsafe-inline' in script-src allows any inline script to run, which largely defeats the XSS protection a CSP exists to provide. 'unsafe-eval' permits eval() and similar. Prefer nonces or hashes for inline scripts, and refactor code away from eval. The generator warns you whenever these keywords weaken your policy.
Where do CSP violation reports go?
If you set a report-uri (or report-to), the browser sends a JSON report to that URL every time the policy is violated. This is invaluable during rollout — you see exactly what would break before you enforce. You can point it at your own endpoint or use the IntoDNS CSP report endpoint to get started.
Does CSP replace X-Frame-Options?
Largely, yes. The frame-ancestors directive controls which sites may embed yours in a frame, and modern browsers prefer it over the older X-Frame-Options header. It is good practice to keep X-Frame-Options too for very old browsers, but frame-ancestors is the authoritative one. Use the full security headers generator if you want both.