What is the new technique that bypasses Content Security Policy using HTML injection and browser caching?

Table of Contents

• What Is Content Security Policy (CSP)?
• What Makes This Attack Different?
• How This CSP Bypass Attack Works
• Understanding the Attack Chain in Simple Terms
• Technical Breakdown: How Cache Manipulation Works
• The Role of CSRF in This Attack
• Why This Is Dangerous for CSP-Enabled Sites
• Which Browsers and Sites Are Affected?
• Recommendations for Developers and Security Teams
• Conclusion
•  Frequently Asked Questions (FAQs)

A team of cybersecurity researchers has discovered a new technique to bypass Content Security Policy (CSP) using a combination of HTML injection and browser cache manipulation. This method challenges one of the core defenses in modern web security and exposes websites to Cross-Site Scripting (XSS) attacks, even when CSP is correctly implemented using nonces.

What Is Content Security Policy (CSP)?

Content Security Policy (CSP) is a security mechanism that allows web developers to control the sources from which content such as JavaScript, CSS, images, and other resources can be loaded.

Most modern CSP implementations use a nonce-based system. This involves generating a unique, random nonce (number used once) for each request. Only scripts or styles with the correct nonce are allowed to execute, thereby preventing unauthorized code injection.

What Makes This Attack Different?

This attack doesn't break CSP itself. Instead, it bypasses the protection by taking advantage of how browsers cache pages—specifically:

• Back/forward cache (bfcache)

• Disk cache

Combined with CSS injection and HTML injection, attackers can leak nonce values and reuse them in malicious scripts.

How This CSP Bypass Attack Works

Understanding the Attack Chain in Simple Terms

1. HTML Injection Enables Entry

The attacker first uses HTML injection to insert custom content into a web page—usually CSS or references to hidden requests.

2. CSS Injection Leaks the CSP Nonce

By targeting the tag that contains the CSP configuration, attackers use CSS attribute selectors to read the nonce value. For example:

meta[content*="nonce-abc"] {
  background-image: url("/leak?char=abc");
}

Each background request leaks part of the nonce, and by overlapping patterns, the attacker can reconstruct the entire nonce.

3. Browser Caches Help Retain the Nonce

Browsers store pages in the bfcache and disk cache. The page, along with the leaked nonce, is preserved and reused. This allows the attacker to inject malicious scripts that still carry the valid nonce.

Technical Breakdown: How Cache Manipulation Works

Modern browsers use Network Isolation Keys to control cache partitioning. These keys are built from:

• Top-level site

• Current frame origin

Attackers exploit this by loading different versions of the page (e.g., /dashboard?xss) to force cache separation. They can then:

• Load the page and leak the nonce

• Exploit a CSRF vulnerability to update the payload

• Navigate back to a cached version that still uses the old nonce

The Role of CSRF in This Attack

The attacker needs to update the page with their malicious payload. This is done by exploiting Cross-Site Request Forgery (CSRF) vulnerabilities, where the application does not validate request origins.

Once the payload is updated and saved on the server, the attacker uses the cached page to run the malicious script with the valid nonce.

Why This Is Dangerous for CSP-Enabled Sites

Main Concerns:

• Many developers assume that nonce-based CSP fully prevents XSS.

• Attackers don’t need to break the CSP engine—they just need to reuse what was already allowed.

• Sites using tags for CSP (instead of headers) are more vulnerable.

Which Browsers and Sites Are Affected?

This technique works across most modern browsers, including:

• Chrome

• Firefox

• Edge

Any web application that:

• Relies on nonce-based CSP

• Outputs CSP in tags

• Lacks strict cache-control headers

• Has CSRF-vulnerable endpoints

…is potentially at risk.

Recommendations for Developers and Security Teams

✅ Use CSP via HTTP headers only

Avoid putting CSP inside tags—these can be read and exploited using CSS.

✅ Disable caching on sensitive endpoints

Set proper Cache-Control headers, such as:

Cache-Control: no-store

✅ Secure all form and POST endpoints against CSRF

Use CSRF tokens and same-site cookies.

✅ Rotate CSP nonces more frequently

Not just per page load—consider nonce rotation for dynamic content.

✅ Monitor for suspicious CSS or image requests

Unusual background-image URLs may signal nonce-leaking attempts.

Conclusion

• This is not a CSP vulnerability—it’s a cache-based bypass.

• Browser behavior can unintentionally preserve valid CSP nonces.

• Developers must rethink their CSP deployment and cache strategies.

• Real-world attacks using this method are feasible and dangerous.