Home / Core Health / Implement a Content Security Policy (CSP) header
Security Headers · Scan Check Guide

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.

The full picture

A Content Security Policy represents one of the more comprehensive and technically substantial security headers available, providing genuine, granular control over which sources of content — scripts, styles, images, and other resources — your browser is permitted to load and execute on your pages, directly addressing cross-site scripting and several other injection-based attack categories.

The genuine protective mechanism here is explicit allowlisting — rather than trusting that all content loaded on your page is legitimate, CSP requires you to explicitly declare which sources are trusted, meaning any malicious script somehow injected from an unauthorized source gets blocked by the browser itself, even if it successfully made it into your page's actual HTML.

This represents genuinely more complex implementation than the other security headers discussed in this broader hardening work — a CSP that's too restrictive breaks legitimate site functionality, while one that's too permissive fails to provide meaningful protection, making careful, genuine testing across your site's actual functionality a necessary part of proper implementation rather than a single, simple configuration value.

The real security value CSP provides, once properly configured and tested, is substantial — this represents one of the most comprehensive available defenses against cross-site scripting specifically, a vulnerability category responsible for a significant share of real-world web security incidents, making the additional implementation complexity a worthwhile investment relative to the genuine protection provided.

How to fix it

  1. 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. 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. 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. 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

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

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. →