Hardening Web Applications with Content Security Policy (CSP)

Understanding the Fundamentals of CSP

Content Security Policy is delivered to the browser via the Content-Security-Policy HTTP response header. It consists of a series of directives, each specifying the allowed sources for a particular type of resource. When a browser receives this header, it strictly enforces these rules, refusing to execute any code or load any resource that doesn't originate from a whitelisted source.

The power of CSP lies in its ability to restrict 'inline' scripts. By default, a strong CSP will block any script tag that doesn't have a specific source attribute, as well as 'eval()' functions and inline event handlers like onclick(). This makes it significantly harder for an attacker who has found an injection vulnerability to actually execute their payload.

Core Directives and Their Usage

To build an effective policy, you need to understand the primary directives that govern resource loading. A policy is only as strong as its most permissive directive. Most developers start with a 'default-src' directive, which serves as a fallback for other directives that aren't explicitly defined.

• default-src: The catch-all for any resource type not specified (e.g., 'self' allowed).
• script-src: Defines valid sources for JavaScript (the most critical directive for XSS protection).
• style-src: Specifies allowed sources for CSS stylesheets.
• img-src: Controls where images can be loaded from.
• connect-src: Limits the URLs which can be loaded using script interfaces (like fetch or XHR).

Constructing a Secure Policy

A common mistake is using 'unsafe-inline' or 'unsafe-eval' because it's easier than refactoring code. However, these keywords negate much of the security benefit of CSP. Instead, modern developers should use nonces (number used once) or hashes to permit specific, trusted inline scripts.

A policy containing 'unsafe-inline' without nonces/hashes is often equivalent to having no policy at all against most XSS threats.

Here is an example of a strict, modern CSP header that uses 'self' as a baseline and allows scripts from a trusted CDN while utilizing a nonce for an inline tracking script:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com 'nonce-2726473854'; object-src 'none'; base-uri 'self';

The Importance of 'object-src' and 'base-uri'

Often overlooked, 'object-src' should almost always be set to 'none' to prevent the execution of legacy plugins like Flash or Java applets. Similarly, 'base-uri' should be restricted to 'self' to prevent attackers from hijacking relative URLs by injecting a <base> tag into your HTML.

Transitioning to Production: Report-Only Mode

Deploying a strict CSP on a legacy site can be dangerous and might break critical features. To mitigate this risk, use the 'Content-Security-Policy-Report-Only' header first. This mode tells the browser to monitor activity and log violations to a specified URL, but it does not actually block any resources.

1. Deploy the 'Report-Only' header with your desired strict policy.
2. Configure a reporting endpoint using the 'report-to' or 'report-uri' directive.
3. Monitor your logs for several days to identify legitimate scripts that were flagged.
4. Adjust your policy to include missed sources or refactor problematic code.
5. Once violations drop to zero, switch to the enforcing 'Content-Security-Policy' header.

Common Pitfalls and Best Practices

One of the most frequent issues is the 'allow-list' approach becoming too bloated. If you whitelist an entire large domain like 'https://cdnjs.cloudflare.com', an attacker can choose any library from that massive repository to assist in their attack. Instead, try to be as specific as possible with URLs or use SRI (Subresource Integrity) in conjunction with your CSP.

Finally, remember that CSP is NOT a replacement for secure coding. It is a safety net. You must still escape your data, use modern frameworks that handle auto-escaping (like React or Vue), and conduct regular security audits.