What Is CSP?

At a glance

A Content-Security-Policy response header can significantly constrain exploitation of injected scripts when configured appropriately.

Turning page resources into an explicit allowlist

Content Security Policy uses response headers or a meta element to declare permitted sources for scripts, styles, images, fonts, frames and connections. Browsers check the policy before using resources, restricting what injected content can do. It is particularly useful as defense in depth against XSS.

Effective CSP is more than a list of external hostnames. Modern policies often authorize trusted scripts using a nonce or hash and propagate trust with strict-dynamic. This can avoid maintaining huge host lists and reduce bypasses through attacker-controlled resources on allowed hosts.

Directives for different attack surfaces

• default-src supplies a fallback for many resource types. script-src, style-src, img-src and connect-src set more specific rules.
• object-src 'none' disables legacy plugin content, base-uri restricts base elements, and frame-ancestors controls which pages may embed this page.
• Nonces and hashes authorize particular inline code. unsafe-inline broadly relaxes restrictions; its interaction with nonces depends on the policy and client behavior.
• report-to or report-uri can collect violations. Report-Only reports rather than blocks, making it useful for observing dependencies before enforcement.

Moving from reporting to enforcement

A careful migration inventories first- and third-party resources, removes unnecessary scripts, generates unpredictable nonces for dynamic pages and reviews Report-Only reports. Extensions, ads and malicious injections add noise, so group reports by page template and resource source.

Adding many hosts plus unsafe-inline and unsafe-eval simply to eliminate errors can leave a policy with little practical restraint. CSP should complement output encoding, safe templates, dependency updates and measures such as Trusted Types, not replace correction of injection flaws.

Practical use and interpretation

A complete policy allows analysis of resource coverage, nonces, hashes, broad sources and reporting. Merely finding the header does not establish policy strength; Content-Security-Policy-Report-Only does not mean violations are blocked.

No CSP means one browser-side protection is absent, not that XSS exists. A broad policy may provide limited restriction, while actual exploitability depends on page inputs and script behavior.

Points to consider

CSP provides defense in depth, not a replacement for input handling, output encoding or dependency security.

Frequently asked questions

Does CSP eliminate XSS?

No. Correct output encoding, DOM handling and dependency management remain necessary. Incorrect or overly broad policies may be bypassed.

How does Report-Only differ from enforced CSP?

Report-Only records violations without blocking resources. Content-Security-Policy enforces the restrictions.

Why avoid long-term reliance on unsafe-inline?

It permits broad inline execution and weakens script-source restrictions. A nonce or hash usually authorizes trusted code more precisely.