Implement a Content Security Policy (CSP) header

1-2 hr Impact: high Effort: medium ✓ Scan-verified — no manual checkbox

A Content Security Policy is an allowlist you send in a response header telling the browser exactly which sources are allowed to load scripts, styles, images, and other content on your page — anything not on the list gets blocked automatically.

CSP prevents cross-site scripting (XSS) by telling browsers which scripts are allowed to run on your page. Without it, any injected script executes freely — the most common client-side attack.

How to fix it

1

Start in report-only mode

Add Content-Security-Policy-Report-Only first so you can see what would break without actually blocking anything yet.
2

Inventory what your site actually loads

Check your browser's network tab for every domain your page pulls scripts, fonts, images, or iframes from (analytics, fonts, embeds, ad tags).
3

Build the policy from that inventory

Start narrow: default-src 'self'; script-src 'self' [your analytics/script domains]; style-src 'self' 'unsafe-inline' [font domains].
4

Switch from report-only to enforced

Once nothing shows violations for a few days, change the header from Content-Security-Policy-Report-Only to Content-Security-Policy.

Common mistakes

Going straight to full enforcement without testing in report-only mode is the #1 way this breaks a live site — third-party embeds silently stop working.
'unsafe-inline' and 'unsafe-eval' defeat much of CSP's protection — use them only as a temporary bridge while you migrate inline scripts to external files.

How you'll know it's done

The CSP header is enforced (not report-only), your site functions normally, and browser console shows no CSP violations on a full page load.

Tools that help

CSP Evaluator ↗

Google's tool for checking a CSP policy for common bypasses and weaknesses.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →