Content security policy: plainly explained.

A content security policy, or CSP, is an HTTP response header that tells the browser exactly which sources of scripts, stylesheets, images, fonts, and other resources a web page is allowed to load. Anything not explicitly allowed by the policy is blocked by the browser before it can execute, regardless of how it ended up in the page. This matters because it directly closes off the main mechanism behind cross-site scripting (XSS) attacks: even if an attacker manages to inject a malicious script tag into a page, a well-configured CSP prevents the browser from ever running it.

CSP is delivered as a standard HTTP header rather than a piece of application code, which means it works as a last line of defense that applies regardless of how the page was built or which framework generated it.

A CSP is a set of directives, each controlling one resource type, sent as a single HTTP header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data:; style-src 'self' 'unsafe-inline'

Here, default-src 'self' sets the fallback rule (only the page's own origin), script-src allows scripts from the page's origin plus one trusted CDN, img-src also allows inline data URIs for images, and style-src allows inline styles. The browser evaluates every resource request against the matching directive and silently blocks anything outside the allowed list, typically logging a console warning that developers can inspect.

• default-src: fallback source list applied to any directive not explicitly set.
• script-src: allowed sources for JavaScript, the directive most responsible for blocking XSS.
• style-src: allowed sources for CSS, including whether inline styles are permitted.
• img-src / font-src / frame-src: allowed sources for images, fonts, and embedded iframes respectively.
• connect-src: allowed destinations for fetch, XHR, and WebSocket connections initiated by the page.

• Start in report-only mode on a production-like environment to see what a strict policy would break before enforcing it.
• Avoid unsafe-inline and unsafe-eval for script-src whenever possible; they weaken the policy's protection against XSS significantly.
• List third-party domains explicitly (analytics, widgets, embeds) rather than using a wildcard, which defeats the purpose of the policy.
• Re-audit the policy whenever a new third-party script or embed is added to the site; a forgotten domain causes silent breakage rather than an obvious error.
• Combine CSP with other security headers, such as an SSL certificate enforcing HTTPS, for layered protection rather than relying on CSP alone.

Cross-site scripting remains one of the most common web vulnerabilities, and a CSP is one of the few defenses that works even after an attacker has already found a way to inject a script into a page, by preventing the browser from executing it. Search engines and security scanners increasingly treat the presence of security headers, CSP included, as a trust signal, and hosting or agency audits often flag its absence. For sites handling forms, logins, or payment data, a CSP is a low-effort, high-impact addition to a site's overall security posture.

We configure security headers, including a content security policy where the hosting stack allows it, as part of the technical hardening we apply to the sites and web apps we build. This sits alongside HTTPS enforcement and dependable web hosting choices as a baseline for any client-facing site. See our website service for how we handle security and technical foundations across the sites we build.