Attacking Microsoft Edge to identify users by leaking URLs from Fetch requests

Apr 16, 2017


I found that Microsoft Edge exposes the URL of any JavaScript Fetch response, in contradiction to the specification. This is a problem because it is possible to identify users by crafting a Fetch request in a webpage that will redirect to a URL containing the visitor’s username (e.g. requesting will result in This may obsolete identification by IP or browser fingerprinting.


Although I am generally less interested in web development issues, I’ve recently had the time to play with some of the relatively new web APIs, such as WebSockets and Service Workers. I tried testing the boundaries of Service Workers, hoping to find anything that compromises the users’ privacy. I didn’t find anything with Google Chrome, but the first few minutes playing with Microsoft Edge I found the following information exposure in the Fetch API.

I would generally not bother writing about this and just let Microsoft resolve it, but their security team refused to acknowledge it as an issue, so I hope that publishing it may convince them otherwise.

Please make yourself familiar with Fetch. In short, it is the cleaner, modern replacement for XMLHttpRequest (XHR).

The Issue

By default, requests made with fetch should respect CORS and deny access to inappropriate resources. However, it is possible to make a request with “no-cors” mode, enabling fetch to bypass CORS. The response of such a request should be “opaque”, meaning it’s content should be empty (so that an attacker could not gain access to cross-origin requests made with the user’s session). The specification states the following:

An opaque filtered response is a filtered response whose type is “opaque”, url list is the empty list, status is 0, status message is the empty byte sequence, header list is empty, body is null, and trailer is empty.

The vulnerability is that in Microsoft Edge the url property of an opaque response is not an empty string, but it is the full URL of the response returned after following redirects.

This may not sound like an issue at first since no confidential information should be stored in the URL. That’s correct. However, many websites use redirection to redirect the user to a personal page. For instance, a website redirecting to

Some real life examples used in the PoC are, and Redirection to the user page is just an example and there are other possibilities to exploit this issue, left to the reader as an exercise.

Proof of Concept

Test your browser or see the GitHub project (run for the Facebook example)

I originally tried to find a Microsoft service that the issue applies to, so the first PoC targets I later modified it a little to target Facebook. The simpler version only proves the URL leak happens with Docs, Facebook and Youtube. Anyhow, the effect is that without any user interaction or consent the user’s identity is leaked to the attacker’s website.

I’ve tested the PoC on Microsoft Edge 40.15063.0.0 (slow ring) and on Microsoft Edge 38.14393.0.0 (current release).

Microsoft’s response

Update (24.4.2017): I’ve reached MSRC once again after this post became popular on Reddit and social media. Their response clarified that they do treat this as a security issue and assured a patch is to come soon.

Final update: Jonathan from MSRC had assigned a CVE for this issue attributed to me in their acknowledgement page.