Content Security Policy (CSP) is a browser-enforced security standard that lets web applications declare allowed sources for content such as scripts, styles, images and frames. It reduces cross-site scripting and injection risks by restricting resource loading and execution. CSP requires careful policy design, reporting, and incremental rollout to avoid brea…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Content Security Policy (CSP) is a browser-enforced security policy that defines which sources a web application may load and execute content from. It helps reduce cross-site scripting and other injection attacks.
The approach grew out of the web-security problem that injected or third-party code could run in a trusted page context. Robert Hansen proposed the idea in 2004 under the name “Content Restrictions”; it later became CSP, was standardized by the W3C Web Application Security Working Group, and evolved through Level 1 (2012) and Level 2 (2014).
Think of CSP as a browser-side decision path. The application sends a policy through an HTTP header or meta tag. The browser compares each potential resource against directives such as script-src, style-src, img-src, connect-src, or frame-ancestors. More specific rules override default-src; nonces and hashes allow narrow exceptions. In report-only mode, violations are reported without being blocked.
Separate rules govern different resource types and embedding scenarios.
A directive allows only defined origins, schemes, nonces, or hashes.
This fallback directive applies when no more specific rule is present.
Inline scripts, inline styles, and dynamic execution are especially constrained.
Violations are made visible before the policy actually blocks anything.
This directive limits which sites may embed a page in frames.
CSP is most useful for public web applications, legacy migrations, and systems that rely on many third-party libraries. The biggest benefit comes when a team can reduce inline code, eval(), and unknown sources. The trade-offs are policy design, monitoring, and frequent adjustments to existing pages; overly strict rules can break features, while overly broad rules protect little. CSP complements input validation and output encoding, but does not replace them.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.