TL;DR
- A Content Security Policy (CSP) is a security standard that helps prevent attacks like cross-site scripting (XSS) by restricting the sources of content a browser can load.
- CSP is vital for protecting user data, stopping malicious scripts, and preventing client-side vulnerabilities.
- CSP defends websites against client-side attacks by controlling which scripts, styles, and assets are allowed to load.
Introduction
Who is this guide for?
This article is for security teams, developers, and privacy professionals looking to strengthen web application defenses.
Why it matters
With growing threats like JavaScript-based malware, data skimming, and DOM manipulation, securing the client-side of web apps is mission-critical. CSP offers one of the most effective ways to do this—by controlling which content can load in the browser.
What you’ll learn
- What CSP is and how it works
- Real-world use cases and benefits
- Examples of CSP headers
- Common implementation pitfalls
- How CSP fits into your security strategy
What is a Content Security Policy?
A Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, including XSS, clickjacking, and JavaScript injection attacks. It allows site owners to specify which content sources are considered trustworthy by browsers.
Think of CSP as a browser-side firewall that controls what the browser can load and execute. This includes JavaScript, CSS, fonts, iframes, and even image files.
How it works
CSP is implemented via HTTP response headers or a <meta> tag. These instruct the browser to block unauthorized content from executing.
Example HTTP Header:
Content-Security-Policy: script-src ‘self’ https://trusted.cdn.com
In this case, the browser only allows scripts from the same domain and trusted.cdn.com.
Why is CSP Important?
Common threats it mitigates:
- Cross-Site Scripting (XSS): Injected scripts are blocked by default unless explicitly allowed.
- Data Injection Attacks: Prevents inline scripts and unauthorized script execution.
- Clickjacking: Using frame-ancestors directive, CSP can restrict iframing.
CSP helps organizations meet compliance standards like PCI DSS 4.0 Requirement 6.4.3, which mandates protections against unauthorized script execution.
Real-World Examples and Use Cases
eCommerce Site Example
A major eCommerce platform might load scripts from:
- its own domain (self)
- third-party analytics
- a payment processor like Stripe
Its CSP might look like:
Content-Security-Policy:
default-src ‘self’;
script-src ‘self’ https://js.stripe.com https://www.googletagmanager.com;
style-src ‘self’ ‘unsafe-inline’;
This policy ensures:
- No rogue scripts can load
- Only specific third-party services are trusted
- Inline styles are allowed cautiously
Real-world Impact
Implementing CSP helped British Airways avoid further damage during the Magecart breach, and companies like Meta and Google rely on CSP as part of their client-side defenses.
Common CSP Directives Explained
Here are some widely used CSP directives:
- default-src: Fallback for all content types not defined.
- script-src: Controls JavaScript sources.
- style-src: Defines where CSS can be loaded from.
- img-src: Restricts image sources.
- connect-src: Limits AJAX, WebSocket, and Fetch endpoints.
- frame-ancestors: Prevents clickjacking by limiting embedding origins.
Best Practices and Pitfalls
Do:
- Start with Content-Security-Policy-Report-Only for testing.
- Use nonces or hashes to allow safe inline scripts.
- Combine with Subresource Integrity (SRI) for stronger guarantees.
Don’t:
- Overuse ‘unsafe-inline’ or ‘unsafe-eval’—these weaken your policy.
- Forget to include third-party resources you need (like fonts or analytics).
- Assume CSP is a silver bullet. It’s one layer in a multi-layered defense.
FAQ
What does a Content Security Policy do?
It restricts the sources of content (like scripts and styles) a browser is allowed to load, helping prevent XSS and other injection attacks.
How do I implement a CSP?
By adding a Content-Security-Policy header in your HTTP response or a <meta> tag in your HTML.
What’s the difference between Content-Security-Policy and Content-Security-Policy-Report-Only?
The former enforces the policy; the latter logs violations without enforcement—ideal for testing.
Can CSP stop all types of attacks?
No. While it’s powerful, CSP should be used alongside other protections like SRI, cookie flags, and secure coding practices.
Is CSP required for PCI DSS compliance?
Yes, under PCI DSS 4.0 (Requirement 6.4.3), organizations must prevent unauthorized scripts from executing in payment pages—which CSP helps enforce.
More Resources
A content security policy is a great resource that every business should be using to defend the client side of their web applications and websites. If you have any more questions about how it works, you can check out more of our resources on it, including our in-depth blog post.
Feroot is dedicated to helping companies, both big and small, protect their web assets, and is passionate about offering solutions that can make client-side security easier. Two of our biggest resources are our client-side security solutions Inspector and PageGuard.
These solutions both work silently in the background, scanning your site for anomalies and immediately reporting on any issues they find. Their robust reporting features allow your team to focus their attention on the day-to-day operation of your business, stepping in to deal with issues as they come up without spending all their time on monitoring and maintenance.
Feroot also developed DomainGuard, a product specifically designed to make content security policies easy to manage, maintain and enhance. DomainGuard automatically generates custom content security policies based on crawls of specified web applications. Once the CSP is deployed, DomainGuard tracks versions and reports on violations.
Demo Inspector, DomainGuard and PageGuard to see these security solutions in action!
