What Is Content Security Policy (CSP)?
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 does Content Security Policy work?
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.
Read it as separate rules: default-src 'self' provides a same-origin resource fallback, object-src 'none' denies object embeds, base-uri 'self' restricts the document's base URL, and frame-ancestors 'none' prevents other pages from framing this page. The semicolons separate directives; they do not describe a sequence of actions.
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.
Each example below is a directive fragment, not a complete policy. Replace example origins with reviewed sources. Script and style examples assume no more-specific element or attribute directives.
default-src
Fallback policy for resource types that do not have a more specific directive.
Example: default-src 'self'; limits images to the page's origin if img-src is absent.
script-src
Controls JavaScript sources, inline script hashes, nonces, and risky values like 'unsafe-eval'.
Example: script-src 'self'; permits same-origin script files. It does not by itself authorize inline scripts or event handlers.
style-src
Controls stylesheets and inline style allowances, including hashes or nonces when used.
Example: style-src 'self'; permits same-origin stylesheets; inline styles need a separate strategy.
img-src
Controls image sources, including common allowances such as same-origin CDNs or carefully reviewed data: images.
Example: img-src 'self' https://images.example; permits same-origin images and one reviewed image host.
connect-src
Controls fetch, XHR, WebSocket, EventSource, and API endpoints.
Example: connect-src 'self' https://api.example; permits same-origin requests and the named API; it does not authorize that API host for scripts.
font-src
Controls web font sources such as local assets, Google Fonts, or a private asset CDN.
Example: font-src 'self'; permits same-origin font files. A stylesheet host and its font-file host may require different rules.
frame-src
Controls iframes and embedded content loaded by your page.
Example: frame-src https://video.example; permits frames from that host. It does not decide who can embed your page.
frame-ancestors
Controls which parent pages may embed your page and helps prevent clickjacking.
Example: frame-ancestors 'none'; prevents framing this page, including from the same origin. Deliver it in an HTTP header.
object-src
Controls legacy plugin content. Most modern policies set this to 'none'.
Example: object-src 'none'; denies resources loaded through <object> and <embed>.
base-uri
Restricts which URLs can be used in a document <base> element.
Example: base-uri 'none'; disallows a document base URL. Review applications that intentionally use <base>.
form-action
Controls where forms can submit data.
Example: form-action 'self'; limits form submission targets to the page's origin. Review external payment or sign-in form destinations separately.
report-to
Names a Reporting API endpoint for CSP violation reports.
Example: report-to csp-endpoint; refers to a group defined by Reporting-Endpoints; it is not a URL or a resource allowance. See the reporting header pair.
Does default-src apply to every CSP directive?
No. It supplies a fallback for resource directives such as img-src and connect-src when their own rule is absent. It does not set base-uri, form-action, or frame-ancestors; configure those separately.
In default-src 'self'; img-src https://images.example;, the explicit image rule replaces the image fallback. Same-origin images are not allowed by that rule unless 'self' is also included in img-src. This example assumes no additional policies.
Some resources have a longer fallback chain: worker-src checks child-src, then script-src, then default-src if the earlier directives are absent. Script and style elements or attributes can also have more specific rules. See the CSP specification's default-src rules.
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.
What is a CSP policy, and how is it different from a CSP header?
The policy is the set of rules, such as script-src 'self'. The HTTP header delivers those rules to the browser under the name Content-Security-Policy. Use CSP policy examples to choose a starting shape and CSP header examples to configure delivery.
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.