What is Content Security Policy?

Content Security Policy (CSP) is one of the most powerful security headers a website can send, and also one of the most misunderstood. In plain terms, a Content Security Policy is an HTTP response header that tells the browser exactly which sources of content it is allowed to load and run on your page: scripts, styles, images, fonts and frames. Anything outside that policy is blocked before it can execute.

What is Content Security Policy in practical terms?

Every time someone visits your site, their browser trusts your server to tell it what is safe to load. Without a Content Security Policy that trust is almost unlimited. If an attacker injects a single line of malicious JavaScript, whether through a vulnerable plugin, a hijacked ad network or a cross-site scripting flaw, the browser will run it without question. A CSP closes that door by acting as a strict allowlist: you declare the origins you trust, and the browser refuses everything else.

How a Content Security Policy works

A CSP is built from a series of directives, each governing one type of resource. The browser reads the policy on every page load and enforces it on each request the page makes. If a script tries to load from an origin you have not approved, it simply never runs.

Common CSP directives

• default-src sets the fallback rule for any resource type you do not define explicitly.
• script-src controls where JavaScript may load from. This is the single most important directive for stopping cross-site scripting.
• style-src controls stylesheets and inline CSS.
• img-src controls which origins may serve images.
• connect-src restricts the endpoints your page can reach with fetch, XHR or WebSockets.
• frame-ancestors decides which sites may embed yours in a frame, defending against clickjacking.

What a Content Security Policy protects against

The headline benefit is defence against cross-site scripting (XSS), still one of the most common and damaging web vulnerabilities. Because a CSP can forbid inline scripts and untrusted origins, an injected payload has nowhere to run. A well-built Content Security Policy also helps with:

• Clickjacking, by using frame-ancestors to stop other sites framing your pages.
• Mixed content and downgrade attacks, by allowing only secure origins.
• Data exfiltration, by limiting the endpoints a compromised script could send information to.

A safe starting policy

A conservative first policy might read: default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-ancestors ‘self’. This tells the browser to load resources only from your own domain, block plugins entirely, and refuse to be framed by third parties. From there you widen the policy carefully, adding the specific trusted origins your site genuinely needs.

Because a strict policy can break legitimate features, most teams begin with the report-only variant, Content-Security-Policy-Report-Only. It reports violations without blocking anything, letting you refine the rules against real traffic before you enforce them.

How to check your Content Security Policy

Reading a policy by eye is slow and error-prone, and a header that looks fine can still leave gaps. An automated scan is the fastest way to confirm your Content Security Policy is present, well-formed and actually protecting visitors. Run a full security scan with EzyAudit AI and you will see your CSP graded alongside every other security header, with plain-English guidance on what to change. If the scan reports the header missing, our guide on how to fix a missing CSP header covers the exact steps. You can also review every check we run on the features page.

For the full directive reference and current browser support, the MDN Web Docs guide to Content Security Policy is the definitive source.

A strong Content Security Policy is one of the highest-value improvements you can make to your security posture. Scan your website now to see exactly where your headers stand and what to fix first.