‘By focusing on XS-Leaks as a fundamental vulnerability class, we help raise their profile and make it easier for developers to understand their impact’

Cross-site leaks (XS-Leak) are a family of browser-side channels that can be used to infer information about users

Cross-site leaks (XS-Leak) are a family of browser-side channels that can be used to infer information about users. Web developers and browser vendors often misunderstand XS-Leak bugs, which can have security and privacy implications for their applications and users.

In an upcoming talk (PDF) at the XS-Leaks Summit, security researcher Artur Janc aims to shed light on some of these misunderstandings. Janc has been working on XS-Leaks for over a decade and has helped document and fix many security issues in web applications and browsers.

In a Q&A with The Daily Swig, Janc shared his perspective on XS-Leaks and what needs to be done.


What is your background and experience in XS-Leak?

I’ve worked on the security of this area for over a decade, since before this type of issue got the name of “XS-Leaks”. This included research on websites’ ability to reveal users’ web browsing histories (PDF) or evaluating how new web APIs, such as the Ambient Light Sensor, could be abused to learn information about a user’s browsing history, and working with web browser vendors to address these issues.

At Google, security engineers on our Information Security Engineering team conduct novel research and follow community developments in this area, with the goal of protecting our applications and the web at large.

Part of my work included reviewing the landscape of cross-origin information leaks (PDF) and working with engineers on our team to launch the xsleaks.dev wiki which is arguably the most comprehensive resource enumerating known XS-Leaks attacks and defenses.


How do you see the evolution of research and mitigation of XS-Leaks in the past few years?

Web browsers have done a good job at giving developers “native” web defenses to protect their applications: Fetch Metadata headers, Cross-Origin Opener Policy, Cross-Origin Resource Policy, SameSite cookies, and others (further information here and here).


RELATED What is Fetch Metadata? How to protect your web resources from information-stealing attacks


They have also shipped certain kinds of XS-Leak protections by default: SameSite=Lax-by-default cookies, Site Isolation (spearheaded by Chrome but now also on the verge of being available in Firefox), and other features that lock down attack vectors that have historically allowed XS-Leaks to occur.

These are all major positive developments for the web because they protect sites from some XS-Leak attack vectors by default and allow developers of particularly sensitive sites to adopt additional opt-in protections for their applications. However, as always in security, there are still gaps that allow attacks which we continue to evaluate and mitigate.


Cross-site leaks are a family of browser-side channels that can be used to infer information about usersCross-site leaks attacks can be used to infer information about users online


Are there any aspects that you think have been overlooked or ignored by developers and browser vendors? Do you see any recurring patterns in XS-Leak vulnerabilities?

With the positive developments mentioned above, the next class of issues that I’d point to as the next “frontier” for XS-Leaks (and for web security in general) are issues in browsers themselves that allow websites to leak some information about the user or their activity on other sites. The :visited history disclosure issue (PDF) is one example, but there are more, for example connection pool exhaustion and other network-level leaks.


Read more of the latest browser security news


These attacks can’t be mitigated by application developers by deploying mechanisms such as Fetch Metadata, CORP or COOP, and they require browsers (and sometimes OS vendors) to make far-reaching changes. Because these issues have long been part of the web platform, browsers may sometimes not perceive them as urgent; the goal of my talk is to remind browser vendors of the impact of :visited history detection and help them prioritize work on fixing them.


Do you think XS-Leaks is an underrated threat, not receiving the attention it deserves
(perhaps like XSS)?

One way that I’d like developers and the security community to consider (and that I argued for in past talks) is that there are only three fundamental classes of security problems on the web: the lack of encryption (issues due to the use of plain HTTP, non-Secure cookies, etc.), injections (XSS), and the lack of isolation between web applications (leading to XS-Leaks, but also other well-known vulnerability classes such as CSRF, XSSI, or clickjacking).

In that sense, XS-Leaks haven’t been underrated, we’ve just considered them to be multiple different vulnerability classes instead of one major problem. By focusing on XS-Leaks as a fundamental vulnerability class (rather than talk about XS-Search, CSRF, and other bugs separately) we help raise their profile and make it easier for web application developers and browser vendors to understand their impact and ways to address them.


What is the goal of your talk? What do you wish to raise awareness of?

As I already alluded to above, I’d like to help point web browser vendors’ attention to the problem of browsing history disclosure using the CSS :visited selector and help them prioritize fixes to improve the overall security/privacy posture of the web platform.


RECOMMENDED Slack contains an XS-Leak vulnerability that de-anonymizes users