Why Your Content Security Policy Might Be Useless - And How to Fix It

In today’s web landscape, safeguarding applications from security threats like Cross-Site Scripting (XSS) is paramount.

One effective measure is the implementation of Content Security Policy (CSP), a security standard designed to prevent such vulnerabilities.

However, traditional CSP configurations that rely on domain whitelisting can be susceptible to bypass techniques and can be difficult or even impossible to maintain.

This article delves into these challenges and introduces the advantages of adopting CSP Level 3’s strict-dynamic directive. I have also developed an open-source tool that simplifies the deployment of strict-dynamic CSPs on any website using Cloudflare Workers.

The Pitfalls of Whitelist-Based CSPs

Traditional CSPs often employ whitelists, specifying trusted domains from which resources can be loaded. While this approach aims to restrict malicious content, it has inherent issues and vulnerabilities:

• Subdomain Exploitation: Attackers can compromise a subdomain within the whitelisted domain, serving malicious scripts that the CSP would inadvertently trust.

• JSONP Endpoints: Some APIs use JSONP to circumvent cross-origin restrictions. If such endpoints exist on a whitelisted domain, attackers can exploit them to execute arbitrary scripts. An example of this can be found on google.com, therefore, *.google.com in a CSP results in a simple bypass. JSONP endpoint bypass | CSP Bypasses

• Dynamic Content: Web applications that dynamically include content from whitelisted domains might unintentionally introduce vulnerabilities, especially if the external content is not adequately sanitized.

• Dynamic adverts can’t be whitelisted: This is a major with sites that heavily use advertising networks such as Google Publisher Tag (GPT). Google state themselves that you can not use CSP whitelists when using GPT. This is a common issue with News sites, and therefore you will find most News sites do not have an effective CSP. Most I have reviewed simple set: script-src: https:, 'unsafe-inline', 'unsafe-eval', blob:, which is not effective at stopping XSS attacks. Google GPT

A comprehensive study highlighted that a significant percentage of real-world CSP deployments are susceptible to such bypasses, rendering the intended security measures ineffective. Google Research

Embracing strict-dynamic for Robust Security

To address the limitations of whitelist-based policies, CSP Level 3 introduces the strict-dynamic directive. This directive shifts the focus from specifying trusted sources to trusting scripts that are explicitly approved by the site’s developers. Here’s how it enhances security:

• Nonce-Based Trust: Developers assign a unique nonce (a random value) to each trusted script. Scripts with a valid nonce can execute and, importantly, can load additional scripts, even from unlisted domains. This ensures that only scripts vetted by the developer can introduce new content. Strict Dynamic

• Simplified Policy Management: By eliminating the need for extensive domain whitelists, strict-dynamic reduces the complexity of CSP configurations, making them easier to maintain and less prone to misconfigurations.

• Enhanced Security Posture: This approach mitigates risks associated with compromised whitelisted domains, as only scripts with the correct nonce can execute, regardless of their origin.

For a deeper understanding of strict-dynamic and its implementation nuances, refer to the Google documentation. Google Strict CSP

Streamlining CSP Deployment with Cloudflare Workers

Implementing a nonce-based CSP can be daunting, especially for large applications with numerous scripts. To simplify this process, I’ve developed a Cloudflare Worker that automates the injection of strict-dynamic CSP headers and assigns nonces to script tags dynamically. This tool offers:

• Automated CSP Header Injection: The worker automatically adds CSP headers with the strict-dynamic directive to your site’s responses.

• Dynamic Nonce Assignment: Each script tag in your HTML is assigned a unique nonce on every request, ensuring that only trusted scripts execute.

• Seamless Integration: Designed to work effortlessly with existing infrastructures, this solution requires minimal configuration changes.

• High performance: The worker is designed to be lightweight and does not impact the performance of your site. In fact, if you’re not already running your site through cloudflare, you will likely find a performance improvement.

• SEO friendly: The worker is designed to be SEO friendly and does not impact the SEO of your site.

• User experience friendly: The worker is designed to be user experience friendly and does not impact the user experience of your site.

• Zero costs: The worker is free to use and does not require any paid services, as Cloudflare offers a generous free tier. The tools is also open source and free to use.

You can see this working in action on this site, just inspect the page and you will see the CSP header has been injected with the strict-dynamic directive and a nonce.

You can access and deploy this tool from the GitHub repository. CSP Strict Dynamic - Cloudflare Worker

Conclusion

Transitioning from traditional whitelist-based CSPs to a strict-dynamic approach significantly bolsters your web application’s defense against XSS attacks. By focusing on trusted scripts and leveraging tools like the Cloudflare Worker for automated nonce management, developers can enhance security while simplifying policy maintenance.

For further insights and practical guidance on implementing a strict CSP, consider exploring resources such as the web.dev guide on mitigating XSS with a strict Content Security Policy. Google Strict CSP

By adopting these advanced strategies, you can ensure a more secure and resilient web application environment.