WebSec tools
6 tools that run in your browser. Nothing to install, nothing uploaded.
Security headers are the part of a site’s defence that lives entirely in configuration, which is why they are so often either missing or copied from a blog post and quietly doing nothing. The Content-Security-Policy builder here writes a policy from what your page actually loads, says what each directive gives up, and starts you in report-only mode so you collect real violations for a week before anything is enforced. It will also tell you when a policy is theatre — a script-src that still allows unsafe-inline is not stopping cross-site scripting, whatever a header-grading scanner scores it.
- Cookie Security CheckAudit Set-Cookie headers for Secure, HttpOnly and SameSite.
- CSP GeneratorBuild a Content-Security-Policy that is worth deploying — starting in report-only.
- Password Policy GeneratorWrite a password policy that reflects current guidance, not 2005.
- Permissions-Policy BuilderBuild a Permissions-Policy header that constrains the third-party code you did not write.
- security.txt CheckerCheck a security.txt file against RFC 9116, including the expiry that makes it valid.
- SRI Hash GeneratorGenerate a Subresource Integrity hash for a script or stylesheet.
Start in report-only, always
A Content-Security-Policy enforced on the first deploy breaks the page for real users, in ways the person who wrote it usually will not see, because the inline script that mattered was in a third-party widget or a template nobody looked at. The Content-Security-Policy-Report-Only header applies the same policy and blocks nothing, sending violation reports instead — so you spend a week collecting what your site actually loads, tighten the policy against real data, and only then switch to enforcement. The generator here starts you in report-only for that reason, and produces both header names so the transition is a one-word change.
Policies that score well and protect nothing
The most common CSP in the wild keeps unsafe-inline in script-src, because removing it means fixing every inline handler and script block on the site. That single directive re-permits exactly the injection the policy exists to stop: an attacker who can insert a script tag is unaffected by a rule that allows inline scripts. A wildcard host, or a policy that omits object-src and base-uri, has similar gaps. Header-grading scanners frequently award a good mark for the presence of the header rather than for what it permits, which is why the builder explains what each choice gives up instead of counting directives.
Nonces, hashes and the path off unsafe-inline
The supported way to keep a genuinely needed inline script is a nonce: a random value generated per response, placed in the header and on the script tag, so only the scripts your server marked will run. It must be unpredictable and it must be new on every request — a nonce reused across responses, or baked into a cached page, provides nothing. For a static script that never changes, a hash of its exact content is the alternative and needs no server-side generation, at the cost of updating the policy whenever that script changes by a single byte.
Frequently asked questions
Will deploying a CSP break my site?
It can, which is exactly why you start in report-only. The Content-Security-Policy-Report-Only header applies your policy and blocks nothing, sending violation reports so you learn what the site actually loads — and it is nearly always more than the person writing the policy expects, because third-party widgets and old templates carry inline scripts nobody remembers. Collect a week of reports, tighten against real data, then switch the header name to enforce.
Can I keep unsafe-inline in my policy?
You can, and it removes most of the protection you were deploying the policy for. An attacker who can inject a script tag is entirely unaffected by a rule that permits inline scripts. The supported alternatives are a per-response nonce for scripts your server marks, or a content hash for a static script that never changes. Neither is free — both mean touching the templates — but a policy that keeps unsafe-inline is mostly a header, not a defence.
Does a good score from a header scanner mean I am protected?
Not reliably. Many scanners grade on the presence of headers rather than on what a policy actually permits, so a CSP with a wildcard host or unsafe-inline can score well while allowing the attack it was meant to stop. Read the directives: what does script-src really permit, are object-src and base-uri set, and would this policy have blocked an injected script tag? That question is the score that matters.
How should nonces be generated?
Randomly, per response, from a cryptographic source, and never reused. The value goes in the header and on each script tag your server intends to allow, so only those scripts run. A nonce that is reused across responses or baked into a cached page provides no protection at all, because an attacker can simply read it and include it — which makes CSP nonces and full-page caching genuinely awkward to combine, and a hash the better option for static scripts.