Paste or build a CSP, review the policy for common weaknesses, and export header snippets for HTTP, Nginx or Apache. The analysis happens in your browser; no input is uploaded.
Runs locally in your browserPaste an existing CSP to inspect it, or use the builder on the right. This tool analyzes only the text you enter.
Enter source expressions without the directive name. Leave a field blank to omit that directive.
Only use HSTS after HTTPS is correctly configured for every relevant subdomain. Review generated values against your application requirements.
Build a CSP, then generate header snippets.
Build a CSP, then generate header snippets.
Build a CSP, then generate header snippets.
A CSP should match the resources your application genuinely needs. Roll it out carefully, consider report-only testing first, and avoid copying a policy between sites without reviewing scripts, frames, APIs, and third-party assets.
This page turns a Content-Security-Policy into three things you can act on: a directive-by-directive review of the text you typed, a finished policy assembled from the builder, and header snippets ready to paste into Nginx or Apache. It reads the policy as text; it never requests your site.
Everything runs inside the tab and no input is sent to VoriTools, so you can review a policy that has not been published yet.
The text is split at semicolons, and each directive is read as a name followed by its source list. Directive names are case-insensitive; everything else is compared as written. Two structural checks come first, because browsers settle them for you and rarely the way the policy author expects: when a directive appears twice, the first value is used and later copies are ignored; when 'none' appears next to other sources, 'none' is ignored rather than enforced.
The review is heuristic, not a validator. It flags what most often weakens a policy in practice - a missing default-src, 'unsafe-inline' or 'unsafe-eval' in script-src, a wildcard or data: script source, and missing object-src, base-uri, frame-ancestors or form-action - but a complete policy can still be wrong for your application, and one that gets a note here can still be correct.
All three outputs carry the same headers: the Content-Security-Policy value you wrote, plus any of the four optional headers you ticked. The HTTP view is plain Name: value lines; the Nginx view wraps each header in add_header ... always; so it is also sent on error responses; the Apache view uses Header always set ... . Quotes and backslashes inside a policy are escaped for the target configuration syntax.
The optional headers are fixed defaults: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), geolocation=(), microphone=() and Strict-Transport-Security: max-age=63072000; includeSubDomains. Review every value against your own requirements; HSTS in particular locks browsers to HTTPS for the max-age you send, so add it only when every subdomain involved is ready.
A CSP is enforced on real responses, not in this editor. A directive that looks strict here can still break a payment script, a font or an inline style the application needs, and the browser console reports exactly which source was blocked. Roll a new policy out with Content-Security-Policy-Report-Only on staging first, then enforce it and keep watching the reports.
The snippets are starting points for your server configuration, not a substitute for it. Whether a header survives depends on your web server, any CDN or proxy in front of it, and the response path that serves the page; check the live response headers after deployment with the browser network panel or a command-line client.