Remove wildcard sources from script-src

Why it matters

A script-src that allows *, http:, https: or data: lets an attacker load a script from any server they control, so the policy does not stop script injection. List the exact hosts you use, or switch to nonces with 'strict-dynamic'.

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 script hosts the site really uses (the developer tools Network tab, filtered to JS, on every page type).
2. Stage 1: send the policy with those hosts instead of the wildcard as Content-Security-Policy-Report-Only and check what is still reported.
3. Stage 2: enforce it. With a nonce and 'strict-dynamic' in script-src, browsers ignore host and scheme sources, so an https: fallback there is fine.

Content-Security-Policy-Report-Only: script-src 'self' https://scripts.vendor.example; 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
• Restrict where scripts can load from
• Replace 'unsafe-inline' scripts with nonces or hashes
• Remove 'unsafe-eval' 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