Sends HTTP response with CSP header
DevOps & Tooling / Knowledge library
Content Security Policy (CSP)
Restricts which browser resources and script sources a page may execute
Why learn Content Security Policy (CSP)?
It reduces the impact of many injection flaws and reports violations
The problem it solves
It narrows executable content even when markup injection occurs
Where it came from
Content Security Policy (CSP) is a security concept that restricts which browser resources and script sources a page may execute. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Content Security Policy (CSP) and distinguish it from a neighboring concept.
- Choose a realistic task where Content Security Policy (CSP) is appropriate.
- Identify a failure mode caused by misusing Content Security Policy (CSP).
- Interpret a small design or result involving Content Security Policy (CSP).
- Explain one tradeoff or limitation of Content Security Policy (CSP).
Documentation and sources
- OWASP Developer Guide: Security Principles (devguide.owasp.org)
Connect the ideas
Explore next
Real World Example
Securing the Retail Dashboard Portal
E-commerce platform administrators managing third-party analytics and marketing scripts.
The business problem
The portal frequently suffers from unauthorized script injection where malicious third-party dependencies attempt to exfiltrate session tokens or manipulate the DOM, bypassing standard input sanitization.
How this topic solves it
Content Security Policy (CSP) acts as a declarative security layer that restricts the browser to only executing scripts from trusted, pre-approved domains. By defining a strict whitelist, the browser automatically blocks any inline scripts or external resources not explicitly authorized in the policy header, effectively neutralizing unauthorized injection attempts.
- Audit all existing third-party scripts to identify required domains for analytics and tracking.
- Draft a CSP header using the Content-Security-Policy directive to define script-src and connect-src sources.
- Deploy the policy in report-only mode to monitor for legitimate traffic violations without breaking functionality.
- Analyze report logs to refine the whitelist and remove unnecessary domains.
- Enforce the policy by switching the header to active mode to block unauthorized execution.
The flow illustrates how the browser validates incoming resources against the defined policy.
Receives policy and enforces constraints
Source matches the whitelist
Source is not in the whitelist
- Web Server → defines policy → Browser
- Browser → executes → Trusted Script
- Browser → blocks → Malicious Script
Implementation example
This header restricts script execution to the origin domain and a specific trusted analytics provider, mapping to the solution of whitelisting domains.
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.analytics.com; connect-src 'self';Expected business outcome
A hardened browser environment where unauthorized scripts are blocked by default, significantly reducing the risk of cross-site scripting and data exfiltration.
Limitations and checks
A overly restrictive policy can break legitimate application features, such as dynamic script loading or third-party widgets. To check for this, developers must monitor the browser console for CSP violation reports and verify that all essential application features remain functional after enforcement.