Content Security Policy (CSP) Header Not Set

ID

content_security_policy_csp_header_not_set

Severity

high

Kind

Security Misconfiguration

CWE

693

Description

Content Security Policy (CSP) is an HTTP response header that instructs browsers which sources of content (scripts, stylesheets, images, frames, etc.) are permitted to load on a page. When the CSP header is absent, the browser enforces no restrictions on content origins, leaving the application exposed to Cross-Site Scripting (XSS), data injection, and clickjacking attacks. A properly configured CSP acts as a defense-in-depth mechanism that significantly reduces the attack surface even when other protections fail.

This detector covers the following sub-variant scenarios:

  • The response does not include any Content-Security-Policy header, so the browser applies no content restrictions at all.

  • The response uses the obsolete X-Content-Security-Policy or X-WebKit-CSP headers instead of the standard Content-Security-Policy header.

  • The response includes a Content-Security-Policy-Report-Only header, which monitors violations but does not enforce any blocking, possibly indicating an incomplete deployment.

Rationale

Without a CSP header, an attacker who finds an injection point can load and execute arbitrary scripts from any origin, enabling theft of session tokens, credentials, and sensitive user data. The browser has no policy to block unauthorized inline scripts, external resources, or embedded frames, so exploitation of even a minor XSS flaw can escalate to full account takeover or malware distribution.

Additionally, the absence of frame-ancestors directives makes the application susceptible to clickjacking, where a malicious site overlays invisible frames to trick users into performing unintended actions.

Remediation

  • Add a Content-Security-Policy HTTP response header to every page served by your application. Configure it on your web server, application server, reverse proxy, or load balancer, depending on your architecture.

  • Start with a restrictive policy and relax it only as needed. A reasonable baseline is default-src 'self', which limits all resource types to the same origin. Then add specific directives such as script-src, style-src, img-src, and frame-ancestors to allow only the origins your application actually requires.

  • Avoid using unsafe-inline and unsafe-eval in script-src, as they negate much of the protection CSP provides. If your application relies on inline scripts, use nonce-based ('nonce-<random>') or hash-based ('sha256-<hash>') allowlisting instead.

  • Deploy the policy in report-only mode first (Content-Security-Policy-Report-Only) with a report-uri or report-to directive to collect violations without breaking functionality. Once you have resolved all legitimate violations, switch to the enforcing Content-Security-Policy header.

  • Remove any obsolete X-Content-Security-Policy or X-WebKit-CSP headers and replace them with the standard Content-Security-Policy header supported by all modern browsers.

References