Security finding
The Content-Security-Policy allows what it is meant to stop
Security Warning Severity: Medium
Part of the audit Security headers. Finding id: security.cspWeak.
What it costs you
The header is there but does not do its job. With 'unsafe-inline', a wildcard or a bare scheme in a script directive, a script injected through a flaw in the site runs as if there were no policy.
What to do
Replace the weak source with a nonce or hash for your own inline scripts and a short list of exact hosts for the rest.
What it checks
- Content security policy missing or unsafe
How to fix it
Move to a nonce-based policy
- Generate a random nonce per response and put it on every script tag you own: <script nonce="...">.
- Send a policy of this shape, with the same nonce: Content-Security-Policy: script-src 'nonce-RANDOM'; object-src 'none'; base-uri 'none'
- If your scripts load further scripts, add 'strict-dynamic' to script-src. The trust of the nonce then extends to what they load.
- Send it as Content-Security-Policy-Report-Only first and read the reports, then enforce it.
- A static page cannot carry a new nonce per response. List a hash for each inline script instead.
How to check: curl -sI [example url] | grep -i content-security-policy (no 'unsafe-inline', no * and no bare https: in script-src)
A real case
A Google study of 1,680,867 hosts found bypasses in 94.72% of the distinct Content-Security-Policies, and 99.34% of the hosts with a policy got no protection against cross-site scripting from it.