Restrict where scripts can load from

Why it matters

The policy sets neither script-src nor default-src, so it does nothing against injected scripts, the main thing a CSP is for. Add a script-src that lists only your own origin and the services you use, or that uses nonces.

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. Stage 1: send the script restrictions as a separate Content-Security-Policy-Report-Only header so the current policy keeps working unchanged, and check the developer console on every page type.
2. Add each legitimate script host it reports, or switch to a per-response nonce with 'strict-dynamic' if your application can generate one.
3. Stage 2: move the directives into the enforced Content-Security-Policy and drop the report-only header.

Content-Security-Policy-Report-Only: script-src 'self'; object-src 'none'; base-uri 'self'

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
• Replace 'unsafe-inline' scripts with nonces or hashes
• 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