/ˌsiː-ɛs-ˈpiː/
n. “Trust nothing by default. Especially the browser.”
CSP, short for Content Security Policy, is a defensive security mechanism built into modern browsers to reduce the damage caused by malicious or unintended content execution. It does not fix broken code. It does not sanitize input. What it does instead is draw very explicit boundaries around what a web page is allowed to load, execute, embed, or communicate with — and then enforces those boundaries with extreme prejudice.
At its core, CSP is a browser-enforced rulebook delivered by a server, usually via HTTP headers, sometimes via meta tags. That rulebook answers questions browsers used to shrug at: Where can scripts come from? Are inline scripts allowed? Can this page embed frames? Can it talk to third-party APIs? If an instruction isn’t explicitly allowed, it is blocked. Silence becomes denial.
The policy exists largely because of XSS. Cross-site scripting thrives in environments where browsers eagerly execute whatever JavaScript they encounter. For years, the web operated on a naive assumption: if the server sent it, the browser should probably run it. CSP replaces that assumption with a whitelist model. Scripts must come from approved origins. Stylesheets must come from approved origins. Inline execution becomes suspicious by default.
This matters because many real-world attacks don’t inject entire applications — they inject tiny fragments. A single inline script. A rogue image tag with an onerror handler. A compromised third-party analytics file. With CSP enabled and properly configured, those fragments simply fail to execute. The browser refuses them before your application logic ever sees the mess.
CSP is especially effective when paired with modern authentication and session handling. Even if an attacker manages to reflect or store malicious input, the policy can prevent that payload from loading external scripts, exfiltrating data, or escalating its reach. This makes CSP one of the few mitigations that still holds value when other layers have already failed.
Policies are expressed through directives. These directives describe allowed sources for different content types: scripts, styles, images, fonts, connections, frames, workers, and more. A policy might state that scripts are only allowed from the same origin, that images may load from a CDN, and that inline scripts are forbidden entirely. Browsers enforce each rule independently, creating a layered denial system rather than a single brittle gate.
Importantly, CSP can operate in reporting mode. This allows a site to observe violations without enforcing them, collecting reports about what would have been blocked. This feature turns deployment into a learning process rather than a blind leap. Teams can tune policies gradually, tightening restrictions as they understand their own dependency graph.
CSP does not replace input validation. It does not replace output encoding. It does not make unsafe frameworks safe. What it does is drastically limit the blast radius when something slips through. In that sense, it behaves more like a containment field than a shield — assuming compromise will happen, then making that compromise far less useful.
Modern frameworks and platforms increasingly assume the presence of CSP. Applications built with strict policies tend to avoid inline scripts, favor explicit imports, and document their dependencies more clearly. This side effect alone often leads to cleaner architectures and fewer accidental couplings.
CSP is not magic. Misconfigured policies can break applications. Overly permissive policies can provide a false sense of safety. But when treated as a first-class security control — alongside transport protections like TLS and authentication mechanisms — it becomes one of the most effective browser-side defenses available.
In a hostile web, CSP doesn’t ask whether content is trustworthy. It asks whether it was invited. Anything else stays outside.