CSP stands for Content Security Policy, a security standard implemented through HTTP response headers that instructs the browser on which resources it is allowed to load and execute for a given page. CSP is one of the most effective browser-side defenses against cross-site scripting (XSS) and other code injection attacks, acting as a safety net even when application-level input handling has flaws.
How It Works
CSP works by declaring a policy that the browser enforces. The policy consists of directives, each controlling a specific resource type. When the browser encounters a resource that violates the policy, it blocks it and optionally reports the violation to a specified endpoint.
Key directives include default-src (fallback for all resource types), script-src (JavaScript sources), style-src (CSS sources), img-src (image sources), connect-src (fetch, XMLHttpRequest, WebSocket targets), font-src (font files), frame-src (iframe sources), and frame-ancestors (which sites can embed this page). Each directive accepts source expressions like 'self' (same origin), specific domains, 'none' (block all), or nonce/hash values for inline resources.
CSP can operate in enforcement mode, where violations are blocked, or report-only mode (Content-Security-Policy-Report-Only), where violations are logged but not blocked. Report-only mode is valuable during initial deployment, allowing teams to identify which legitimate resources would be blocked before switching to enforcement. The report-uri or report-to directive specifies where the browser should send violation reports.
A strict CSP using nonces, where each inline script must include a server-generated random token, provides the strongest protection against XSS because attackers cannot predict the nonce value required to make their injected scripts execute.
Why It Matters
CSP is a critical defense layer that security assessments always evaluate. A missing or weak CSP means the application has no browser-enforced protection against script injection. Common weaknesses include overly broad source lists, use of unsafe-inline or unsafe-eval, and inclusion of CDN domains that host user-uploadable content. Each of these weaknesses can be exploited to bypass the intended protections.
Need your application tested? Get in touch.