Secure

CSP Evaluator — Is Your Policy Actually Doing Anything

This parses a Content Security Policy and reports what it actually permits, flagging the constructions that undermine it. The gap between having a policy and having an effective one is enormous, and it is entirely invisible from the fact that a policy header is present.

When it helps

Because most policies in the wild are decorative. The overwhelmingly common pattern is a policy containing unsafe-inline for scripts, which permits exactly the injected inline script the policy exists to prevent — added during rollout because the site broke without it, and never removed. Overly broad source expressions have the same effect more subtly: allowing a whole CDN means allowing anything anyone else has published there. A policy with either of those passes a compliance checklist and stops nothing.

Worth running automatically

Policies drift toward permissiveness under deadline pressure. Each new third-party integration needs another source added, and the quickest way to make something work is always to loosen the policy — so the policy that was strict at launch is broad two years later, one reasonable exception at a time. Evaluating it on a schedule makes that drift visible. Collecting violation reports is the complementary half: it tells you what a policy is blocking, which is what lets you tighten one safely rather than guessing.

What you get out of it

The difference between a policy that exists and a policy that works. Given that the most common weakness defeats the entire purpose, this is worth running against any policy you inherited.

Also in Secure