What is a Content Security Policy (CSP)? Definition
On this page
A Content Security Policy (CSP) is a set of rules a site sends to the browser listing where the page may load scripts and other resources from and send data to.
How it works
MDN describes CSP as "a series of instructions from a website to a browser" that restrict what the site's code is allowed to do (MDN). The policy is usually sent as a Content-Security-Policy response header. It can also be placed in a meta tag in the page, but that form "does not support all CSP features".
A policy is a list of directives separated by semicolons. The ones site owners meet most often (MDN reference):
default-src: the fallback for any resource type without its own rule.script-src: where JavaScript may come from.connect-src: which addresses scripts may send requests to.img-srcandstyle-src: where images and styles may come from.frame-ancestors: which sites may embed your page in a frame.
The browser blocks anything the policy does not allow and reports it in the developer console. Stricter policies use a nonce, a random value that must be different for every response, so only script tags carrying it can run. Adding 'strict-dynamic' lets those trusted scripts load further scripts, which MDN notes makes the policy somewhat less strict.
To try a policy safely, send it as Content-Security-Policy-Report-Only. The browser then reports violations without blocking anything; report-only mode cannot be set in a meta tag.
Why it matters for your website
CSP is mainly a defense against cross-site scripting, where injected code runs on your pages. MDN is clear that it adds to good input handling rather than replacing it: sites should sanitize input "and set a CSP, providing defense in depth".
It also explains a common support puzzle. When a site with a CSP adds a website widgetA website widget is a ready-made piece of functionality, such as a chat box or booking calendar, that a site adds by pasting a short code snippet. and the widget silently never appears, the policy is usually blocking the vendor's script or its API calls. The fix is to add the vendor's addresses to the right directives, not to remove the policy.
Example
A site's policy before adding a chat widget:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.analytics.example; img-src 'self' data:The widget loads from widget.example.com and calls api.widget.example.com. The updated policy keeps every existing source and adds the two new ones:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.analytics.example https://widget.example.com; connect-src 'self' https://api.widget.example.com; img-src 'self' data:Without the connect-src line, the script would load but every request it made would fall back to default-src 'self' and be blocked. ASDK's install troubleshooting guide shows the same change for its own widget.
Related terms
- Website widget: third-party code that a policy must allow.
- OAuth: another way sites limit what connected apps can do.
- Prompt injection: a different kind of injected input, aimed at AI models.
Sources
- Content Security Policy (CSP) guide (MDN Web Docs) — accessed October 21, 2026
- Content-Security-Policy header reference (MDN Web Docs) — accessed October 21, 2026