One of the basic features of the web platform is that it allows developing websites that mix the functionality of multiple sites. This flexibility allows someone to, for example, create an ad and host it on their site, but also display it on a different site. Or, for example, for someone to upload a profile picture on one website and display it on a different website. This concept is basic to the web (commonly known as a web mashup), and has enabled creating web applications that would otherwise not have been possible (think about how many websites are able to embed YouTube videos, Google Maps, search boxes, login buttons etc.).

However, some applications either don't expect to interact with other sites, or if they do, they only want to interact in some limited way. But, because of the way the web was created, web applications inadvertently leak private information that is not mean to be public by default. Browsers have responded to this issue by providing tools to websites to defend against these leaks, and web developers have worked on adopting these tools without breaking existing functionality. However, given that the web is "open by default", every time a new class of leaks is discovered to be exploitable, or every time a browser introduces a new type of defense, web developers have to experiment with these defenses and adopt them.

Google web applications and services are no exception, and in late 2018 and early 2019, research in this area lead to significant advances in our understanding of the accuracy and effectiveness of these attacks. In order to fix these issues, we have been working hard to roll out broad mitigations across Google.

Conclusion

We've deployed XSLeak mitigations across most Google web applications and we are interested in vulnerability reports that guide us in our efforts to fix any remaining XSLeaks across Google. Thus, we're focused on vulnerability reports that:

1. Demonstrate bypassing our XSLeak mitigations. To identify this class of issues, look for endpoints that enable COOP and Fetch Metadata isolation (note that FM isolation deployments can be identified by the presence of a Vary: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site response header).
2. Demonstrate significant impact from exploiting endpoints that lack XSLeak mitigations. For this scenario, it is important to demonstrate that a vulnerability is impactful and practical to exploit in the real world.
   • Generally, reports that are unable to reliably leak information or that only leak a small amount of information may be rejected during triage or not rewarded by the panel. For example, a bug that only works 10% of the time or that only leaks the user's timezone may be closed as invalid.

Some XSLeak issues can be difficult to fix (since patches often require deep changes to how an application works, or in some cases we even have to work with browser vendors on fixes), and thus might take a longer time to address than other security bugs. Unfortunately, this means that if you report a bug that we already know about, the report would be treated as a duplicate. Sorry about that!

In addition, vulnerability reports for acquisition domains not listed as T0 or T1 are out-of-scope since we are still working to deploy XSLeak mitigations for many acquisitions.

Independent of the VRP, we are also more than happy to hear about new types of attacks. If you are interested in working with us to research this area, check out the XS-Leaks Wiki that some members of the security community (some of which are part of Google's security team) have been working on.