Cybersecurity glossary
What is Content Security Policy (CSP)?
Learn what Content Security Policy (CSP) is, how directives restrict script and resource loading, how nonces and hashes harden XSS defenses, and how to roll out CSP without breaking production.
Definition
Content Security Policy (CSP) is an HTTP response security mechanism that tells browsers which sources of scripts, styles, images, frames, and other content are allowed to load or execute for a page, reducing the impact of injection attacks such as cross-site scripting.
Why Content Security Policy matters
Cross-site scripting remains one of the most common web flaws because applications continually mix HTML, scripts, and untrusted data. Even mature teams ship injection bugs. Content Security Policy (CSP) gives the browser a second opinion: only listed script sources, nonces, or hashes may execute.
CSP also constrains where pages can be framed, which plugins may run, and which endpoints may receive data in some configurations. Used carefully, it shrinks the blast radius of markup injection. Used carelessly—with unsafe-inline everywhere and * allowlists—it becomes paperwork that fails when needed.
How CSP works
The server sends a Content-Security-Policy header (or meta tag in limited cases) containing directives. The browser enforces those directives while rendering the page.
Define an intended resource policy
Decide which origins and patterns are required for scripts, styles, images, fonts, frames, and connections.
Emit the policy on responses
Send Content-Security-Policy or Report-Only headers from the origin or edge.
Browser evaluates each resource
Loads and inline executions are allowed only if they satisfy the matching directive.
Block or report violations
Enforcing mode blocks; report endpoints receive violation details for tuning.
Prefer nonces or hashes for scripts
Trusted inline scripts carry a per-request nonce or a hash listed in script-src.
Tighten iteratively
Remove unsafe fallbacks and overly broad host wildcards as the application modernizes.
Important directives at a glance
script-src
Controls JavaScript sources. The highest-impact directive for XSS mitigation.
default-src
Fallback policy for resource types without a more specific directive.
frame-ancestors
Restricts who may embed the page; key clickjacking control.
object-src
Limits plugins/objects; often set to 'none' on modern sites.
base-uri
Contains base element injection that could rewrite relative URLs.
connect-src
Constrains fetch, XHR, WebSocket, and similar connections from the page.
Nonces, hashes, and strict policies
A strong approach avoids blanket unsafe-inline for scripts. Instead, each response generates a cryptographically strong nonce, includes it in script-src 'nonce-...', and stamps trusted script tags with the same nonce. Hashes can allow specific inline blocks without nonces. strict-dynamic helps trusted scripts load additional scripts in modern browsers when designed correctly.
| Approach | Benefit | Risk if misused |
|---|---|---|
| Host allowlists only | Simple mental model | JSONP/CDN gadgets and broad wildcards weaken XSS defense |
| Nonces / hashes | Blocks unauthenticated inline injection more reliably | Nonce reuse or leaking nonces into caches breaks safety |
| Report-Only first | Safe discovery of breakages | Never graduating to enforce leaves XSS unmitigated |
| unsafe-inline + unsafe-eval | Compatibility with legacy code | Often nullifies CSP’s XSS value |
Rollout checklist
- Inventory first-party and third-party scripts, styles, and frame embeds before writing policy.
- Start with Content-Security-Policy-Report-Only and a reachable report collector.
- Adopt nonces or hashes for scripts; eliminate unsafe-inline as quickly as feasible.
- Set frame-ancestors for clickjacking defense on sensitive HTML responses.
- Avoid * scheme/host wildcards except during temporary migration windows.
- Ensure CDNs and reverse proxies do not strip or overwrite CSP unexpectedly.
- Do not cache personalized nonce responses as public shared content.
- Pair CSP with output encoding, sanitization, and SRI for third-party static scripts.
Limits and pitfalls
CSP does not fix insecure APIs, CSRF, or server-side injection. It also struggles when product teams require arbitrary customer-provided HTML/script without a strong sanitizer. Browser differences and legacy policies (such as relying on X-Frame-Options alone) create uneven protection if headers are incomplete across all routes.
Another pitfall is celebrating a deployed CSP that still contains script-src 'unsafe-inline' 'unsafe-eval' https: data:. That policy may reduce some risks but offers weak XSS containment.
The practical takeaway
Content Security Policy (CSP) instructs browsers which content may load and execute for a page. Its best-known use is reducing XSS impact through careful script-src design, complemented by framing controls and other directives.
Treat CSP as iterative hardening: measure in Report-Only, enforce a strict policy, and keep secure coding as the foundation. A strong CSP is specific, monitored, and free of convenient exceptions that invite script injection back in.
Related security terms
Cross-Site Scripting (XSS)
The injection class CSP is most often deployed to mitigate.
Clickjacking
Framing attacks addressed in CSP through frame-ancestors.
Subresource Integrity (SRI)
Hash integrity for third-party scripts that complements CSP allowlists.
Cross-Site Scripting (XSS)
Deep dive on XSS exploitation and remediation beyond browser policy.
Frequently asked questions
What is Content Security Policy in simple terms?
CSP is a set of rules a website sends to the browser saying which scripts and other resources are allowed. If an attacker injects a malicious script from a disallowed source, the browser can block it.
Does CSP replace input validation and output encoding?
No. CSP is a defense-in-depth control. Secure coding that prevents injection remains primary. CSP reduces damage when markup or script injection still occurs.
What is a CSP nonce?
A nonce is a random per-response value placed in the CSP header and on trusted script tags. Browsers allow only scripts that carry the matching nonce, which helps avoid broad unsafe-inline policies.
What is Content-Security-Policy-Report-Only?
Report-Only sends the same policy semantics but does not enforce blocks. It is used to collect violation reports and tune a policy before switching to enforcing mode.
Can CSP stop all XSS?
No. Weak policies with unsafe-inline, overly broad wildcards, or JSONP gadgets can still allow script execution. Strong CSP significantly raises attacker cost but is not absolute.
Which CSP directive helps with clickjacking?
frame-ancestors controls which parents may embed the page. It is the modern replacement focus for many X-Frame-Options use cases.
How should teams roll out CSP safely?
Inventory script sources, start in Report-Only, fix legitimate violations, tighten directives gradually, then enforce. Monitor reports continuously after enforcement.
References
Explore authoritative guidance and frameworks related to content security policy (csp).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.