Every website you visit loads dozens of resources behind the scenes -- scripts, stylesheets, fonts, images, and more. Most of these come from the site itself or trusted third parties. But what happens when an attacker manages to slip a malicious script into the mix? Without the right protections, the browser has no way to tell the difference between legitimate code and something dangerous. That is exactly the problem Content Security Policy was designed to solve.
CSP is one of the most effective HTTP security headers available today. It gives site owners precise control over what content a browser is allowed to load, dramatically reducing the risk of script injection attacks. Whether you are building a website, managing one, or just trying to understand what makes one site safer than another, understanding CSP is well worth your time.
What Is Content Security Policy?
Content Security Policy is an HTTP response header that tells the browser which sources of content are permitted on a given page. When a server sends back a CSP header, it includes a set of directives -- rules that define where scripts, styles, images, fonts, frames, and other resources can come from.
For example, a basic CSP might say: only load scripts from my own domain and from a specific CDN. If any other script tries to execute -- whether injected by an attacker, embedded in a compromised ad network, or introduced through a browser extension -- the browser blocks it and logs a violation.
The header itself looks something like this in its simplest form:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
The default-src 'self' directive sets the baseline: only allow content from the site's own origin. The script-src directive then adds a specific exception for scripts from a trusted CDN. Everything else gets blocked.
Why CSP Matters: The XSS Problem
The primary threat CSP addresses is cross-site scripting (XSS). XSS is one of the most common and dangerous vulnerabilities on the web. It occurs when an attacker finds a way to inject JavaScript into a page that other users will load. Once that script executes in a victim's browser, it runs with the same permissions as the legitimate page. That means it can steal session cookies, capture keystrokes, redirect users to phishing pages, or even modify the content the user sees.
XSS attacks come in several forms. Reflected XSS involves tricking a user into clicking a crafted URL that causes the server to echo malicious code back into the page. Stored XSS is even worse -- the malicious script is permanently saved on the server (in a database, comment field, or user profile) and served to every visitor who views that content.
Without CSP, the browser has no mechanism to distinguish between a script the site intended to load and one an attacker injected. CSP changes that equation by giving the browser an explicit allowlist. If a script does not match the policy, it does not run. Period.
Key CSP Directives You Should Know
CSP offers a range of directives that control different types of content. Here are the ones you will encounter most often:
- default-src -- the fallback policy for any resource type not covered by a more specific directive
- script-src -- controls where JavaScript can be loaded from, and whether inline scripts are allowed
- style-src -- controls where CSS can come from
- img-src -- restricts image sources
- connect-src -- limits where the page can make network requests (fetch, XMLHttpRequest, WebSocket)
- frame-src -- controls which origins can be embedded in iframes
- font-src -- restricts where fonts can be loaded from
- object-src -- controls plugins like Flash (almost always set to
'none'today) - base-uri -- restricts what URLs can appear in the
<base>element - form-action -- limits where forms on the page can submit data
One of the most important aspects of script-src is controlling inline scripts. By default, a strict CSP blocks all inline JavaScript -- meaning <script> tags embedded directly in the HTML will not execute. This is intentional, because inline scripts are the primary vector for XSS attacks. If your application relies on inline scripts, you can allow specific ones using a nonce (a unique, per-request token) or a hash of the script content, rather than broadly enabling all inline code.
How to Implement CSP on Your Site
Rolling out CSP does not have to be an all-or-nothing decision. Most sites benefit from a phased approach:
Start with report-only mode. Before enforcing a policy, use the Content-Security-Policy-Report-Only header. This tells the browser to log violations without actually blocking anything. It lets you see what would break if you turned enforcement on, without disrupting your live site.
Build your policy based on real usage. Review the violation reports to understand which resources your site loads and where they come from. Use that information to construct a policy that covers your legitimate sources while blocking everything else.
Enforce the policy. Once you are confident the policy will not break functionality, switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Continue monitoring violation reports after enforcement, since new features or third-party changes can introduce unexpected sources.
Refine over time. CSP is not a set-and-forget header. As your site evolves -- adding analytics tools, chat widgets, new CDNs -- your policy needs to evolve with it. Regular reviews keep your policy both functional and secure.
For most sites, the CSP header is set at the web server or application level. If you use Nginx, Apache, or a framework like Next.js or Express, there are straightforward ways to add and manage the header in your configuration.
How CSP Works Alongside Other Security Headers
CSP is powerful on its own, but it works best as part of a layered security approach. Several other headers complement what CSP does:
HSTS ensures that every connection to your site happens over HTTPS rather than HTTP, preventing attackers from intercepting traffic before encryption kicks in. While CSP controls what content loads on the page, HSTS protects the connection itself.
X-Frame-Options (or the CSP frame-ancestors directive) prevents your site from being embedded in a malicious iframe, blocking clickjacking attacks. X-Content-Type-Options stops browsers from misinterpreting file types, which can otherwise be exploited to execute scripts disguised as harmless files.
Together, these headers form a strong defensive perimeter. A site with a well-configured CSP, active HSTS, and the right supporting headers is significantly harder to attack. Missing any one of them leaves a gap that attackers can exploit -- and those gaps are often what leads to malware infections and data breaches.
How to Check If a Site Uses CSP
You do not need to dig through source code to find out whether a site has CSP in place. There are a few quick ways to check:
- Use the HTTP headers checker to inspect the response headers for any domain. It will show you the full Content-Security-Policy header (or flag that it is missing) along with every other security header the site returns.
- Run a domain report for a broader view of a site's security posture, including headers, SSL status, DNS records, and more.
- Check the SSL and transport layer configuration with the SSL checker to make sure the secure connection that CSP depends on is properly set up.
If a site is missing CSP entirely, that is a meaningful signal. It does not necessarily mean the site is compromised, but it does mean the browser has no instructions for blocking injected content -- leaving visitors more exposed than they need to be.
Building a Safer Web, One Header at a Time
Content Security Policy is not a silver bullet. No single security measure is. But CSP is one of the most impactful steps a site owner can take to protect visitors from script injection, data theft, and a range of other attacks that exploit the browser's trust in the content it loads. The best part is that it costs nothing to implement -- it is just a header, a few lines of configuration that stand between your users and a wide category of threats.
If you run a website, start with report-only mode and work toward a strict, enforced policy. If you are evaluating a site's trustworthiness, check for CSP alongside other security headers using the HTTP headers checker. A site that takes the time to configure CSP is one that takes your security seriously.