Replace 'unsafe-inline' scripts with nonces or hashes

Why it matters

With 'unsafe-inline' any script an attacker manages to inject into the page runs, which cancels most of what a CSP protects. Nonces or hashes let only the inline scripts you wrote run.

Staged change. Do this in stages and check each one before the next, so a mistake does not break your site or your mail.

The fix

1. List the inline code: script blocks, onclick and other on* attributes, and javascript: links. Attributes and javascript: links cannot carry a nonce; move them into script files or addEventListener calls.
2. Have the application generate a fresh random nonce for every response, put it in the header and in a nonce attribute on each script tag you own. For fixed inline scripts on static pages, use their sha256 hashes instead.
3. Stage 1: send the policy below as Content-Security-Policy-Report-Only. Browsers that understand nonces or 'strict-dynamic' ignore the https: and 'unsafe-inline' fallbacks, which only keep old browsers working.
4. Stage 2: enforce it. A full-page cache must not serve one nonce to many visitors; use hashes for cached pages or exclude them from the cache.

Content-Security-Policy-Report-Only: script-src 'nonce-RANDOM_PER_RESPONSE' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none'

Read the documentation ↗(opens in a new tab)

Related

• Reported by the Content-Security-Policy check
• Add a Content-Security-Policy
• Enforce the report-only Content-Security-Policy
• Send the Content-Security-Policy as an HTTP header
• Restrict where scripts can load from
• Remove 'unsafe-eval' from script-src
• Remove wildcard sources from script-src
• Set object-src to 'none'
• Add base-uri to the Content-Security-Policy
• Reduce reliance on inline styles
• Fix the Content-Security-Policy syntax