Content Security Policy builder, importer, risk checker and server snippet generator
Build a Content Security Policy for WordPress, static sites, dashboards and APIs. Start from presets, import an existing header, review unsafe directives, generate report-only or enforcing headers, copy Apache, Nginx, Netlify and Vercel snippets, and follow a safe rollout plan before blocking production assets.
Deploy report-only first. CSP is powerful, but an enforcing policy can break ads, analytics, embeds, forms or WordPress plugins if sources are missing.
A CSP should be rolled out carefully, not copied blindly
A Content Security Policy can reduce the impact of cross-site scripting, clickjacking, mixed content and unexpected third-party assets. It can also break a site instantly if it blocks a required script, stylesheet, font, image, frame, form or analytics call. That is why a good CSP builder should show the final header, the risk tradeoffs, the missing hardening directives and the server snippets needed to test safely.
This CSP header builder is designed for practical deployment. It includes WordPress, static site, SaaS and strict starter profiles, imports existing headers, normalizes smart quotes, warns about unsafe-inline, unsafe-eval, wildcards and HTTP sources, creates report-only or enforcing headers, and generates snippets for Apache, Nginx, Netlify, Vercel and meta tag fallback. The goal is not to produce a perfect policy in one click; it is to help you ship a better policy without breaking production.
How to test a Content Security Policy
Start in report-only mode and browse the pages that matter: homepage, article page, login page, checkout or forms, embedded videos, ad slots, analytics, comments and admin workflows. Review console violations and reports, then add only the domains that are truly needed. When reports are clean, switch to enforcement and keep monitoring after plugin, theme or tag-manager changes.
- default-src is the fallback for many resource types.
- script-src is the most sensitive directive for XSS risk.
- object-src ‘none’ blocks legacy plugin content.
- base-uri ‘self’ limits injected base tags.
- frame-ancestors controls who can embed the page.
Common CSP debugging examples
If a script is blocked, prefer adding the exact host rather than a wildcard. If inline scripts are required by WordPress or a tag manager, use report-only first and plan a nonce or refactor later. If fonts fail, check both style-src for the CSS provider and font-src for the font files. If YouTube embeds break, frame-src usually needs the YouTube host. If forms stop submitting, review form-action.
Common questions
Should I use report-only first?
Yes. Report-only lets you see violations without blocking users. It is the safest starting point for existing sites.
Is unsafe-inline always bad?
It weakens script protection. It may be needed temporarily on complex WordPress sites, but treat it as technical debt.
Can I put CSP in a meta tag?
Sometimes, but HTTP headers are better and support more directives. Use meta tags only as a fallback when headers are not available.
What does a Content Security Policy protect against?
Mainly cross-site scripting and data injection. By whitelisting the sources scripts, styles and other resources may load from, a CSP blocks injected or third-party code from executing.
Why should I avoid unsafe-inline and unsafe-eval?
They re-open the exact hole CSP is meant to close by allowing inline and dynamically evaluated scripts. Prefer nonces or hashes for the inline scripts you genuinely need.
How do I roll out a CSP without breaking the site?
Start with Content-Security-Policy-Report-Only to collect violations without enforcing, fix the legitimate sources, then switch to the enforcing header once the reports are clean.
