Content Security Policy (CSP) Explained
Content Security Policy (CSP) is a browser security control, usually sent in the Content-Security-Policy HTTP response header. It tells the browser which sources may load scripts and other resources, limiting the impact of cross-site scripting (XSS) and related content-injection attacks.
What CSP helps protect against
A well-designed CSP can restrict unauthorized script execution, unexpected framing or embedded content, unapproved network destinations, and other browser resource loads. It can also upgrade insecure requests. CSP is especially valuable for reducing the impact of some XSS and injected-content vulnerabilities.
What CSP does not replace
CSP does not make vulnerable code safe and does not replace output encoding, input handling, sanitization, dependency security, authentication controls, or application testing. Treat it as an additional browser-enforced layer.
How Content Security Policy works
The browser receives a policy as a set of directives. Each directive governs a resource type or browser behavior. A source list then identifies allowed origins, schemes, nonces, hashes, or keywords for that directive.
If a page tries to load or execute something that the enforced policy does not allow, the browser blocks it. In report-only mode, the browser reports the violation without applying the block, which lets teams observe expected and unexpected behavior before enforcement.
A small CSP header example
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';This example is a teaching aid, not a drop-in production policy. Real applications usually need explicit directives for their scripts, styles, images, fonts, frames, forms, and connections.
Compact CSP directive glossary
These are the directives most often involved when you create a CSP, validate a generated policy, or read browser violation reports.
default-src
Fallback policy for resource types that do not have a more specific directive.
script-src
Controls JavaScript sources, inline script hashes, nonces, and risky values like 'unsafe-eval'.
style-src
Controls stylesheets and inline style allowances, including hashes or nonces when used.
img-src
Controls image sources, including common allowances such as same-origin CDNs or carefully reviewed data: images.
connect-src
Controls fetch, XHR, WebSocket, EventSource, and API endpoints.
font-src
Controls web font sources such as local assets, Google Fonts, or a private asset CDN.
frame-src
Controls iframes and embedded content loaded by your page.
frame-ancestors
Controls which parent pages may embed your page and helps prevent clickjacking.
object-src
Controls legacy plugin content. Most modern policies set this to 'none'.
base-uri
Restricts which URLs can be used in a document <base> element.
form-action
Controls where forms can submit data.
report-to
Names a Reporting API endpoint for CSP violation reports.
What report-only means in CSP
Content-Security-Policy-Report-Only reports violations without blocking content, while Content-Security-Policy enforces the rules. See the focused CSP Report-Only Header Guide for setup steps, reporting directives, and violation examples.
How CSP nonces and hashes work
A nonce is an unpredictable value generated for each HTTP response and applied to both the policy and the intended inline script or style element. A source hash authorizes inline content whose exact bytes match the hash in the policy.
CSP supports SHA-256, SHA-384, and SHA-512 source hashes. Script Sentinel's optional scanner hashing currently emits SHA-256 sources for non-empty inline content observed on scanned pages. Because hashes are content-sensitive, they must be regenerated when the inline content changes. Script Sentinel does not create or inject per-response nonces.
Common CSP mistakes
- Using
*, broad schemes, or wide subdomain wildcards without reviewing the trust they grant. - Depending on
'unsafe-inline'or'unsafe-eval'when a nonce-, hash-, or code-refactoring strategy is feasible. - Copying a generic CSP example directly into production without matching it to the application.
- Enforcing before testing authenticated, interactive, and conditional flows.
- Treating a CSP scanner as proof that every application state or third party is safe.
- Deploying a policy once and never reviewing it as the site changes.
Browser support and further reading
Modern browsers broadly support CSP, but individual directives and reporting features differ. Check current compatibility for the directives you plan to use.
CSP Explained: Common Questions
What does CSP stand for?
CSP stands for Content Security Policy, a browser security standard for controlling which content and behaviors a page may use.
How does a Content Security Policy work?
The browser reads the policy's directives and source lists, then blocks resource loads or behaviors that an enforced policy does not allow.
What are CSP directives?
CSP directives are rules for specific resource types or browser behaviors. For example, script-src controls scripts and frame-ancestors controls which sites may frame the page.
Does CSP prevent every XSS vulnerability?
No. CSP can restrict what injected content may load or execute, but it does not fix vulnerable code and can be weakened by broad source expressions.
Build a CSP from observed browser evidence
Scan selected public pages, inspect the candidate, and begin report-only testing.