Hardening Web Apps: A Guide to Content Security Policy (CSP)

The Fundamentals of Content Security Policy

Content Security Policy is delivered to the browser via the 'Content-Security-Policy' HTTP response header. It operates on a 'deny-by-default' principle. If a source is not explicitly permitted in your policy, the browser will refuse to load or execute it. This is a massive shift from the default browser behavior, where a script tag pointing anywhere on the internet is generally executed without question.

The strength of a CSP lies in its directives. Each directive controls a specific type of resource. For example, 'script-src' governs JavaScript, while 'img-src' governs images. By defining a granular policy, you ensure that even if an attacker manages to inject a <script> tag, the browser will see that the attacker's domain is not in your whitelist and block the execution.

Crafting Your Baseline Policy

The safest way to start is with a 'default-src' directive. This acts as a fallback for other directives that you don't explicitly define. A common starting point for developers who want to maximize security is to set everything to 'self', meaning resources can only be loaded from the application's own origin.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com; style-src 'self' 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com;

In the example above, we allow scripts from our own domain and one external trusted source. We also allow inline styles using 'unsafe-inline'—though this should be avoided if possible in favor of external stylesheets or nonces/hashes. Using 'self' is a great first step toward eliminating third-party data exfiltration.

Mitigating XSS with Nonces and Hashes

One of the biggest hurdles in implementing CSP is dealing with inline scripts. Historically, developers used 'unsafe-inline', but this effectively disables much of the XSS protection CSP provides. Modern CSP (Level 2 and 3) provides two better alternatives: Nonces and Hashes.

• Nonces: A unique, cryptographically strong random string generated for every single request. You add this string to both your CSP header and your script tags.
• Hashes: You provide a SHA-256 (or better) hash of the script content in your header. The browser only runs scripts whose content matches that hash.
• Strict Dynamic: A modern keyword that allows scripts with a valid nonce to load additional scripts they need, simplifying complex dependency chains.

Nonces are generally preferred for dynamic applications. When you generate a nonce on the server, you include it in your header like 'script-src 'nonce-ed3829ad2''. Only scripts on the page that include 'nonce="ed3829ad2"' will run. An attacker won't be able to guess the nonce for their injected script, so it will be blocked.

Best Practices for Deployment

Deploying a strict CSP on a legacy site can be dangerous and may break functionality. To avoid this, use the 'Content-Security-Policy-Report-Only' header first. This header does not block any resources but sends a JSON report to a URL you specify every time a violation occurs.

1. Start with a highly restrictive policy in Report-Only mode.
2. Monitor your reporting endpoint for legitimate resources being flagged.
3. Adjust your policy to include those legitimate sources.
4. Once reports fall to zero, switch the header to enforcement mode.
5. Regularly audit your allowed domains to remove those no longer in use.

A Content Security Policy is not a silver bullet, but it is the most effective second line of defense we have against the injection of malicious content into trusted environments.

Handling Special Cases and Third-Party Assets

Many modern web apps rely on third-party services like Google Analytics, Stripe, or Intercom. Each of these requires specific additions to your CSP. For instance, Google Analytics usually requires entries in 'script-src', 'connect-src', and 'img-src'. It is vital to consult the official documentation of your third-party providers to get the exact CSP requirements, as they often change.

Lastly, pay attention to the 'frame-ancestors' directive. This directive controls which sites can embed your page in an iframe. Setting this to 'none' or 'self' prevents Clickjacking attacks, ensuring that an attacker cannot wrap your site in a transparent layer to trick users into clicking buttons unintendedly.