In a recent cybersecurity competition, I’ve come across a cross-site attack technique long forgotten. This is something that I thought browsers and web apps are working hard to prevent. I never thought that I would stumble upon the fascinating topic of cross-site leaks, or XS-Leaks.

Imagine a user logging into their bank account on www.bank.com. After logging in, this user now clicks on an ad banner on a social media site, which directs them to www.malicioussite.com. Cross-site controls in the browser prevent JavaScript on www.malicioussite.com from issuing requests to www.bank.com with the user’s cookie. If there were no controls, the malicious site could perform a bank transfer using the bank API without the user knowing.

Nowadays, these attacks are difficult, if not impossible to pull off. Browsers use a wide array of controls to prevent cross-site attacks. Among them are the following:

• Same-origin policies in browsers
• Secure cookie configuration to prevent cookies leaking across sites.
• Cross-Origin Read Blocking (CORB), implemented by Chrome, but not Firefox
• Browsers adding stricter CORS checks over the years and locking down fetch and XMLHttpRequest methods
• No-CORS fetch requests with strict opaqueness: WHATWG specification

Web app developers have many ways they can get browsers to help them further lock down their apps. These are methods that browsers widely support:

• Content Security Policies (CSP) to restrict what content a website can run
• Cross-site request forgery (CSRF) protection in web apps
• Strict Cross-origin resource sharing (CORS) policies in web apps

Yet, just these methods aren’t enough to prevent third parties from stealing information from your users. Most of these controls address active meddling with cross-site resources, such as issuing API requests to other sites on the user’s behalf.

Imagine now that you log onto your health care provider’s website at www.hospital.com. While using social media, you open a malicious ad which redirects you to www.malicioussite.com, under control of a threat actor. What if this threat actor can secretly steal personal information from www.hospital.com, just because you visited www.malicioussite.com? Health care providers may store the following information about you:

• Your home address
• Your date of birth or stated gender
• Your payment account information and billing history
• Your recent diagnosis results or medical imagery
• Your vaccination history or history of other medical procedures

Instead of actively meddling, threat actors sometimes use creative methods to steal private information called side-channel attacks. Many web apps and browsers expose side-channels or aid in making them easier to access by accident. When your health care provider website lets a third party website steal information from you using a side-channel, that website has a cross-site leak vulnerability. When a threat actor uses this cross-site leak to steal information from you, they perform a cross-site leak attack.

The OWASP foundation shares this presentation from 2010 on how to detect and prevent side-channel vulnerabilities. It covers the general topic but not cross-site leaks specifically, though. The threat landscape has changed in the last 15 years.

In these 15 years, researchers have identified new cross-site attacks and better vulnerability analysis techniques. With new attacks and techniques, the potential impact becomes bigger and bigger.

Side-channel leaks work independently of most browser protection mechanisms. You need to examine and resolve each potential side-channel in your web app individually and with great care.

This article contains three useful resources on cross-site leaks that I’ve found over the last few months.

XS-Leaks Wiki

To get a better overview of what’s possible and how to prevent cross-site leaks, I recommend visiting the XS-Leaks Wiki. There, you can find detailed descriptions of attacks and recommendations for defense mechanisms.

When browser developers add new features, new cross-site leaks can emerge as an unintended consequence. Thus, the threat landscape is constantly changing. Both browser developers and app developers need to stay aware of how these changes may affect them.

The XS-Leaks Wiki’s overview of attacks is helpful and lets you get a better feel for what kind of attacks are possible right now. Understanding is half of the battle.

The next two sections introduce two papers that stand out for their systematic approach to categorizing cross-site leaks.

A formal model and tool to test for cross-site leaks

XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers

• DOI link: https://doi.org/10.1145/3460120.3484739
• Direct PDF link

In 2021, Knittel et al. methodically describe cross-site in the browser using a model-based approach. They define a formal model that exhaustively captures possible cross-site leaks. Based on this model they then describe a tool called XSinator that can automatically test browsers for cross-site leak vulnerabilities. XSinator uses the formal model to automatically test each potential vulnerability across many browsers.

You can run XSinator yourself right now. It’s available at the following address:

https://xsinator.com/

I ran XSinator with Firefox 136 on macOS 15 for this article. XSinator showed me 12 exploitable cross-site leaks. The following table shows the 12 cross-site leaks and their description as shown on XSinator.

The paper and the XSinator page contain a detailed description of what each test result means. I invite you to try XSinator yourself.

XSinator and its paper are from 2021. The fact that my browser still remains vulnerable to cross-site leaks shows that this topic remains relevant in 2025.

Referring to the evaluation results in section 6 of the paper, you see that Chromium/Blink engine-based browsers had the most cross-site leak vulnerabilities in 2021. This highlights the dangers of a browser monoculture. Chrome, Edge, Opera, and Brave browser using the same code base increases the risk of a supply chain attack for browser vendors.

Citation:

Lukas Knittel, Christian Mainka, Marcus Niemietz, Dominik Trevor Noß, and Jörg Schwenk. 2021. XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS ‘21). Association for Computing Machinery, New York, NY, USA, 1771–1788. https://doi.org/10.1145/3460120.3484739

Cross-site leak detection in the document object model

Finding All Cross-Site Needles in the DOM Stack: A Comprehensive Methodology for the Automatic XS-Leak Detection in Web Browsers

• DOI link: https://doi.org/10.1145/3576915.3616598
• Direct PDF link

In this paper from 2023 Noß et al. expand on previous research on cross-site leaks. The authors develop a graph-based formal model for Document Object Model (DOM)-based cross-site leaks.

The paper describes a tool called AutoLeak that automatically identifies these DOM cross-site leaks. Using this approach, the authors identify 5 new types of cross-site leaks. The results for AutoLeak described in the paper are available at the following address:

https://autoleak.org/

The authors have made the tool itself available, if you wish to run the AutoLeak tests yourself. You can find it here:

https://github.com/RUB-NDS/AutoLeak

Like with XSinator, the authors of this paper have created a method to exhaustively map the browser attack surface according to a formal method. AutoLeak uses a graph-based DOM-traversal algorithm that maps DOM properties.

For each possible cross-site leak scenario in the model, AutoLeak triggers a state transition in the browser by performing a cross-site action. AutoLeak then observes the differences in the DOM graph before and after the action. These subtle differences in the DOM tree can let an attacker infer the result of a cross-site request.

By exhaustively traversing and diffing the DOM graph, the authors were able to find hard to spot and unexpected cross-site leaks in most browsers.

Cross-site actions include triggering the browser’s Payment Request API and inferring whether you are paying for something on a different site. Nothing’s secure until proven otherwise.

It’s only a question of time until bad actors start using these techniques for fingerprinting or information extraction.

Citation:

Dominik Trevor Noß, Lukas Knittel, Christian Mainka, Marcus Niemietz, and Jörg Schwenk. 2023. Finding All Cross-Site Needles in the DOM Stack: A Comprehensive Methodology for the Automatic XS-Leak Detection in Web Browsers. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS ‘23). Association for Computing Machinery, New York, NY, USA, 2456–2470. https://doi.org/10.1145/3576915.3616598

Conclusion

Web browser and apps become more complex every year. Adding more features increases the risk of adding side-channels. Without careful examination and testing, browsers can aid in enabling new kinds of cross-site leak vulnerabilities. No one wants to become a stepping stone in an attack chain, but the entirety of software is moving towards becoming one.

No shortcuts exist when it comes to protecting your user’s information. Refer to the page on Defense Mechanisms on the XS-Leaks Wiki to learn what actions web app developers can take today.