Is your website leaking sensitive information?

There has been a lack of attention for XSLeaks (cross-site leaks) which result in the leaking of user information

Tuan Nhu Dinh


Most developers are familiar and aware of the security vulnerabilities XSS (Cross-site scripting), CSRF (Cross-site request forgery) or SQL Injection, but there has been a lack of attention for XSLeaks (cross-site leaks) which can result in the leaking of user information. In this blog, I am going to give a brief introduction to it.

What is XSLeaks?

XSLeaks is a class of vulnerabilities where a third party malicious website is able to send requests or redirect users to the target services and then measure side channel signals (e.g. time of the response, static resources caches in browser, HTTP response status code, response content, etc ..) to infer and gather information about users based on such side channel signals.

Real-world example: you are reading my blog, what if I know who you are ??

In 2013, there was a reported bug that allowed a website to use Facebook to detect if a visitor was a particular person. The preview-image for a Facebook Badge was dynamically generated based on a user’s Facebook ID at that time. If user 1234567 was logged in, the image would look something like Fig1. If other users tried to load the badge image for user 1234567, a Facebook logo image was loaded instead of the profile image (Fig2). Basically, only the user themselves could view their profile badge preview.

Fig1. Valid logged-in user. Fig2. Invalid logged-in user.

Even though Facebook had well blocked the information of name and email address, it still leaked the user identity. Hacker could use a JavaScript to silently load profile bade previews for a list of predefined user ids and then check the height and width of the response image to know that a particular user was viewing their page.

If the above example is quite outdated for you, there is another reported bug in mid-2018. Tom Anthony discovered a way that could achieve a similar result. Today, most Facebook backend endpoints are well protected compared to 2013, they are loaded with access-control-allow-origin, x-frame-options headers to prevent the malicious website to embed and investigate the FB content using XHR request, iframe, image tag, …. However, Tom found out one api (with user ID as a param) gave different content-type for matched user and non-matched user. He then used a simple JavaScript script that would take a list of user IDs and generate many script tags with src equals to the endpoint. The script tags would of course fail but they fail in different ways due to the differences in response content type, and it can be detected via onload and onerror event handlers. Moreover, there did not seem to have any sort of rate limiting for that endpoint and he could check thousands of IDs for a minute.

If the above bugs were not fixed, people could have used them to stalk particular people (such as the boss, ex-girlfriend, celebrities ..) reading their blogs or they could show different contents depending on who was visiting. More real world examples about XS-Leak attacks can be found here.

The nature of web application generally ends up with a large number of web-exposed endpoints revealing sensitive data about users and browser implementation makes the websites easily vulnerable to XSLeak attacks. Luckily, XSLeak is firmly on the radar of browser makers and there are some mechanisms to avoid it.


Using X-Frame-Options: DENY results any attempt to load your page in a frame fail. It does not only defend against clickjacking but it also helps to defend against XSLeaks. If the page needs to be embedded in other sites (ads, widgets, and so on) the information contained inside it should be as constant and predictable as possible.

SameSite cookies

In some cases, malicious websites can delete the cache for a specific resource of the attacked sites, force the browser to render those information again and check if the browser really caches the resource that was originally deleted. This allows an attacker to figure out if a website loads a specific resource (such as an image, script, or stylesheet) and results in identifying a user or disclosing some information about him.

Strict same-site cookies can help to avoid the above cases as it differentiates between requests generated by the user manually typing a URL, clicking a bookmark, or clicking on a link from the current site vs. requests initiated by other websites.

You can refer to this link for more details about this kind of attack.

Fetch Metadata request headers

Modern browsers implement sec fetch headers to provide servers more context of the circumstances of why/where the request was triggered. Those information help servers quickly reject requests based on testing a set of preconditions.

For example, a request generated by a img element would result in a request containing the following HTTP request headers:

Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

The server can implement a policy checking over the endpoint and quickly reject the request of non-image content using Sec-Fetch-Dest.

Research in the field of XSLeak attacks is ongoing and I do believe there will be more techniques revealing in the next few years. As a developer, it is important to realise how serious the issue is and start paying more attention to protect your websites from this kind of attack.



Leave a Comment