Content Security Policy, or CSP, is a security policy sent in HTTP response headers. It complements server-side protections by giving the browser a precise list of allowed scripts, styles, images, fonts and connections.
What is a CSP for?
When a page contains injected content, a browser may execute a script or load a resource controlled by a third party. A restrictive CSP reduces this possibility: anything that has not been explicitly allowed is blocked.
It is particularly useful against some consequences of an XSS vulnerability. It can prevent unauthorized scripts from running, restrict the destinations a page can contact and prevent a malicious site from embedding the page in an iframe.
A CSP does not remove the original vulnerability. Input validation, output escaping, updates and other application controls remain essential.
Essential directives
| Directive | Purpose | Key consideration |
|---|---|---|
default-src | Defines the fallback rule | Start with a restrictive value |
script-src | Controls scripts | Avoid broad sources and inline scripts |
style-src | Controls stylesheets | Gradually move inline styles to files |
img-src | Controls images | Allow only necessary schemes and domains |
connect-src | Restricts browser network calls | List required APIs, telemetry and WebSockets |
frame-ancestors | Controls who may embed the page | Use 'none' when no iframe is needed |
object-src | Controls legacy embedded content | 'none' suits most modern websites |
base-uri | Restricts the base element | Reduces relative URL redirection |
What does a restrictive policy look like?
Content-Security-Policy: default-src 'self';
script-src 'self';
style-src 'self';
img-src 'self';
connect-src 'self';
object-src 'none';
base-uri 'self';
frame-ancestors 'none'Do not copy this example blindly. A website using an external service, remote font or API must precisely declare the corresponding source. The goal is not to accumulate allowed domains, but to start from actual needs.
Configurations that create a false sense of security
The presence of the header is not enough. A policy can be technically valid and still remain overly permissive.
*allows a source that is far too broad;'unsafe-inline'allows content embedded directly in the page;'unsafe-eval'enables risky forms of dynamic evaluation;- generic schemes such as
data:orblob:broaden accepted content; - a long list of third-party domains increases the trust surface;
- a missing directive may leave the fallback rule to decide.
Risk depends on context. Allowing data: for images does not have the same impact as allowing it for scripts. Each directive must therefore be assessed according to the type of resource involved.
Strengthen CSP without breaking the website
- Inventory resources actually loaded. List necessary scripts, styles, images, fonts, iframes and network calls.
- Define a restrictive policy. Start with
default-src 'self', then open only justified directives. - Test in report-only mode. The
Content-Security-Policy-Report-Onlyheader reports violations without blocking resources. - Fix dependencies. Move inline scripts and styles to files, remove unused sources and prefer local assets where appropriate.
- Enable blocking gradually. Test essential desktop and mobile journeys before general rollout.
- Monitor regressions. A new integration may require a precise policy adjustment.
How to check a website's CSP
In browser developer tools, open the Network tab, reload the page and inspect the HTML response headers. The console also reports blocked resources and the directive involved.
Then review the effective policy: number of directives, overly broad sources, risky values and protections such as frame-ancestors, object-src and base-uri. Automated analysis makes this easier, but the result must still be interpreted according to the site's actual behavior.
Check your domain's security headers
The TechAtelier audit analyzes CSP and other HTTP signals to highlight missing or overly permissive directives.
Audit a domainUseful protection when it remains precise
A good CSP follows a simple principle: allow only what the page needs. It must be tested, understood and maintained like the rest of the security configuration.
The more precise the policy, the fewer possibilities unexpected content has in the browser. The best result combines a properly secured application, a restrictive CSP and regular monitoring of changes.
Published on 1 September 2026.