Add a Content-Security-Policy

Why it matters

Without a CSP the browser runs any script that ends up in your pages, so a single injection bug gives an attacker control of what visitors see and do. A policy limits where scripts, frames and plugins may load from.

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, report only: send the starter policy below as Content-Security-Policy-Report-Only. It blocks nothing and reports what it would block.
2. Collect the reports. Without a collector, open every page type (home, login, checkout, forms, embeds) with the browser's developer console open. With a collector, add Reporting-Endpoints: csp="https://your-collector/csp" and append ; report-to csp (plus report-uri https://your-collector/csp for browsers without the Reporting API).
3. Add each legitimate source the reports show (analytics, fonts, payment, video embeds) to the matching directive. For inline scripts, prefer a per-response nonce with 'strict-dynamic' or hashes over 'unsafe-inline'.
4. Stage 2, enforce: when the reports stay clean, send the same value as Content-Security-Policy. Never hard-code a nonce in static config; it must be random for every response and must not be cached.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'

Read the documentation ↗(opens in a new tab)

Related

• Reported by the Content-Security-Policy check
• 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
• 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