Content Security Policy (CSP) Generator and Analyser
Build, validate and analyse Content-Security-Policy headers.
Start from a preset
Directives
Other settings
Nonces and hashes
A nonce must be random and new on every response, so your server has to insert it. Use this one to test, and add the same value as nonce="..." on your script tags.
Use via API
Build a Content-Security-Policy from directive lines (as header, meta tag, Nginx and Apache config) with a security analysis, or analyse an existing policy for risky settings. Send JSON, get JSON back.
POST https://pithlab.com/api/v1/tools/csp-header-generator
curl https://pithlab.com/api/v1/tools/csp-header-generator \
-H "Authorization: Bearer $PITHLAB_KEY" \
-H "Content-Type: application/json" \
-d '{"mode":"build","directives":"default-src '\''self'\''\nscript-src '\''self'\'' https://cdn.example.com\nobject-src '\''none'\''\nframe-ancestors '\''none'\''","upgradeInsecureRequests":true}'About the CSP Header Generator
Build a Content-Security-Policy header from presets and directives, with nonces and hashes, then copy it for Nginx, Apache or a meta tag, or analyse a policy.
How to use the CSP Header Generator
- Start from a preset such as Basic site or With Google Analytics 4, or build from scratch.
- Tick keywords like 'self' for each directive and add hosts such as https://cdn.example.com. Invalid sources are flagged and left out.
- Use a nonce or paste an inline script to get its hash, rather than allowing 'unsafe-inline'.
- Copy the policy as an HTTP header, an Nginx or Apache line, or a meta tag, and review the warnings below it.
- To review an existing policy, switch to Analyse and paste the header value.
Examples
Input
Preset: Basic site
Output
Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests
Input
default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'
Output
High (script-src): 'unsafe-inline' lets any inline script run, which defeats most XSS protection. Use nonces or hashes instead.
Input
console.log("hello");Output
'sha256-N4H5TqgSuzNDfekEngS8OvQaDnOXFksFc3nAjDsKxIk='
Frequently asked questions
Why is 'unsafe-inline' a problem?
Most cross-site scripting attacks inject inline script. Allowing 'unsafe-inline' in script-src lets that script run, so the policy stops very little. Use a nonce on each script tag, or a hash of each inline script, and modern browsers will then ignore 'unsafe-inline'.
What does 'strict-dynamic' do?
It lets scripts loaded by an already trusted (nonced or hashed) script run too, and makes browsers ignore host allowlists and 'self'. That makes nonce-based policies practical for sites that load third-party tags. Without a nonce or hash it blocks every script.
Which directives does a meta tag ignore?
A <meta http-equiv> policy cannot use frame-ancestors, report-uri, report-to or sandbox, and cannot be report-only. The tool removes them from the meta output and lists them. Send the policy as an HTTP header when you can.
Do I need object-src and base-uri if I set default-src?
object-src falls back to default-src, but setting object-src 'none' explicitly blocks plugins even if default-src is relaxed later. base-uri and form-action never fall back to default-src, so set them yourself.
How should I roll out a new policy?
Send it first as Content-Security-Policy-Report-Only with a report-to or report-uri endpoint, fix what it reports, then switch to enforcing. Nonces must be random and different for every response. Your policy is built and analysed in your browser and is not sent anywhere.