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

A newly discovered cybersecurity technique combines HTML injection, CSS-based nonce leakage, and browser cache manipulation to bypass Content Security Policy (CSP) protections. By extracting nonce values from meta tags and leveraging browser cache behaviors like bfcache and disk cache, attackers can execute malicious scripts with valid CSP nonces. This attack exposes web applications to XSS risks, even when they use proper CSP configurations.

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

Table of Contents

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

Stage Technique Used Purpose
1 HTML Injection Injects malicious CSS or HTML into the page
2 CSS Injection Extracts CSP nonces from meta tags
3 Cache Manipulation Stores and reuses nonce-loaded pages
4 CSRF Exploit Updates payload via vulnerable endpoints
5 Trigger Exploit Uses browser cache to execute malicious script with valid nonce

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.

FAQs

What is Content Security Policy (CSP)?

CSP is a web security feature that controls which scripts and resources can be executed or loaded by a webpage to prevent XSS attacks.

How does this new attack bypass CSP?

It leaks CSP nonce values via HTML and CSS injection, then uses browser caching to reuse those values for malicious script execution.

What role does HTML injection play in this attack?

HTML injection allows attackers to insert custom content like CSS that can extract sensitive CSP nonce values.

What is a nonce in CSP?

A nonce is a random value added to script tags and declared in CSP to ensure only trusted scripts run.

How is the nonce leaked in this technique?

Attackers use CSS attribute selectors on meta tags to leak nonce values character by character.

Why can’t CSP protect against this bypass?

Because CSP relies on browser behavior, and browser caching can reuse old pages with known nonce values.

What is the bfcache?

The back/forward cache (bfcache) stores the exact page state for fast navigation, including CSP nonces.

How does disk cache factor into the attack?

Disk cache retains entire pages, including their nonce, allowing the attacker to reload a trusted page later.

Can this attack work on all browsers?

Yes, it works across major modern browsers including Chrome, Firefox, and Edge.

What is the role of CSS injection in this technique?

CSS is used to create background-image requests that leak individual characters of the nonce.

Why are meta tags more vulnerable?

Nonce values in meta tags are accessible via CSS, unlike those in script tags which are protected.

What is a Network Isolation Key?

It is used by browsers to partition cache entries by top-level and frame origin, which attackers manipulate to control caching.

What is Cross-Site Request Forgery (CSRF)?

CSRF is when unauthorized commands are transmitted from a user the website trusts, often used here to update payloads.

How does CSRF help the attacker?

It allows the attacker to update stored malicious payloads on the victim site using leaked nonce values.

Can attackers execute JavaScript using this method?

Yes, if the malicious script is injected and paired with a leaked nonce, it bypasses CSP and executes.

What’s the main risk of this bypass?

It defeats one of the core defenses against XSS in modern web apps, exposing users to full script injection.

How can developers prevent this?

Use CSP headers instead of meta tags, set strict cache-control headers, and rotate nonces more frequently.

Should CSP be declared in headers or meta tags?

Always prefer headers—meta tags are more accessible to attackers and less secure.

What cache headers should be used to prevent reuse?

Use Cache-Control: no-store or similar directives to prevent browsers from saving the page.

Is nonce-based CSP still safe to use?

Yes, but only when implemented with proper nonce rotation, secure delivery, and cache protection.

How does cache manipulation enable this attack?

Attackers use URL changes and frame separation to create distinct cache entries that they can control.

What tools can detect nonce leaks?

Advanced web application firewalls and log analyzers that detect unusual background image requests.

How serious is this vulnerability?

It’s very serious—it bypasses protections that were considered robust, enabling stored XSS in secured apps.

Is this a browser vulnerability?

Not exactly—it’s a flaw in how applications interact with browser features like cache, not the browser itself.

Why is CSP so widely used?

CSP is effective at blocking most script-based attacks, making it a critical part of modern web defense.

Can this be exploited in single-page apps?

Yes, SPAs relying on meta tag CSPs are particularly vulnerable due to client-side rendering and history handling.

What’s the best mitigation strategy?

Combine CSP headers, strict cache controls, CSRF protection, and active monitoring.

What is the significance of this research?

It challenges long-standing assumptions about nonce-based CSP, urging a re-evaluation of frontend security.

How does this impact web developers?

It requires developers to update security practices, especially around caching and nonce management.

Where can I learn more about secure CSP implementations?

Refer to Mozilla Developer Network (MDN), OWASP guidelines, and recent browser security whitepapers.



Join Our Upcoming Class!