DISCLAIMER: FingerprintJS does not use this vulnerability in our products and does not provide cross-site tracking services. We focus on stopping fraud and support modern privacy trends for removing cross-site tracking entirely. We believe that vulnerabilities like this one should be discussed in the open to help browsers fix them as quickly as possible. To help fix it, we have submitted a bug report to the WebKit maintainers, created a live demo, and have made a public source code repository available to all.
In this article, we discuss a software bug introduced in Safari 15’s implementation of the IndexedDB API that lets any website track your internet activity and even reveal your identity.
We have also published a demo site to see the vulnerability in action:
Update (Monday January 17th 2022): Apple engineers began working on the bug as of Sunday, have merged potential fixes, and have marked our report as resolved. However, the bug continues to persist for end users until these changes are released.
IndexedDB is a browser API for client-side storage designed to hold significant amounts of data. It’s supported in all major browsers and is very commonly used. As IndexedDB is a low-level API, many developers choose to use wrappers that abstract most of the technicalities and provide an easier-to-use, more developer-friendly API.
Like most modern web browser technologies, IndexedDB is following Same-origin policy. The same-origin policy is a fundamental security mechanism that restricts how documents or scripts loaded from one origin can interact with resources from other origins. An origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it.
Indexed databases are associated with a specific origin. Documents or scripts associated with different origins should never have the possibility to interact with databases associated with other origins.
In Safari 15 on macOS, and in all browsers on iOS and iPadOS 15, the IndexedDB API is violating the same-origin policy. Every time a website interacts with a database, a new (empty) database with the same name is created in all other active frames, tabs, and windows within the same browser session. Windows and tabs usually share the same session, unless you switch to a different profile, in Chrome for example, or open a private window. For clarity, we will refer to the newly created databases as “cross-origin-duplicated databases” for the remainder of the article.
The fact that database names leak across different origins is an obvious privacy violation. It lets arbitrary websites learn what websites the user visits in different tabs or windows. This is possible because database names are typically unique and website-specific. Moreover, we observed that in some cases, websites use unique user-specific identifiers in database names. This means that authenticated users can be uniquely and precisely identified. Some popular examples would be YouTube, Google Calendar, or Google Keep. All of these websites create databases that include the authenticated Google User ID and in case the user is logged into multiple accounts, databases are created for all these accounts.
The Google User ID is an internal identifier generated by Google. It uniquely identifies a single Google account. It can be used with Google APIs to fetch public personal information of the account owner. The information exposed by these APIs is controlled by many factors. In general, at minimum, the user's profile picture is typically available. To learn more, refer to Google's People API documentation.
Not only does this imply that untrusted or malicious websites can learn a user’s identity, but it also allows the linking together of multiple separate accounts used by the same user.
Note that these leaks do not require any specific user action. A tab or window that runs in the background and continually queries the IndexedDB API for available databases, can learn what other websites a user visits in real-time. Alternatively, websites can open any website in an iframe or popup window in order to trigger an IndexedDB-based leak for that specific site.
We checked the homepages of Alexa’s Top 1000 most visited websites to understand how many websites use IndexedDB and can be uniquely identified by the databases they interact with.
The results show that more than 30 websites interact with indexed databases directly on their homepage, without any additional user interaction or the need to authenticate. We suspect this number to be significantly higher in real-world scenarios as websites can interact with databases on subpages, after specific user actions, or on authenticated parts of the page.
Firstly, when followed, the same-origin policy is an effective security mechanism for all window modes. Websites with one origin should never have access to resources from other origins regardless of whether a visitor is using private browsing or not unless it’s explicitly allowed via cross-origin resource sharing (CORS).
In this case, private mode in Safari 15 is also affected by the leak. It’s important to note that browsing sessions in private Safari windows are restricted to a single tab, which reduces the extent of information available via the leak. However, if you visit multiple different websites within the same tab, all databases these websites interact with are leaked to all subsequently visited websites. Note that in other WebKit-based browsers, for example Brave or Google Chrome on iOS, private tabs share the same browser session in the same way as in non-private mode.
We created a simple demo page that demonstrates how a website can learn the Google account identity of any visitor. The demo is available at safarileaks.com. If you open the page and start the demo in an affected browser, you will see how the current browsing context and your identity is leaked right away. Identity data will only be available if you are authenticated to your Google account in the same browsing session.
Moreover, the demo detects the presence of 20+ websites in other browser tabs or windows, including Google Calendar, Youtube, Twitter, and Bloomberg. This is possible because database names, which those websites interact with, are specific enough to uniquely identify them.
The supported browsers are Safari 15 on macOS, and essentially all browsers on iOS 15 and iPadOS 15. That is because Apple’s App Store guidelines require all browsers on iOS and iPadOS to use the WebKit engine.
To reproduce the leak yourself, simply call the indexedDB.databases() API. In case websites opened in other frames, tabs, or windows interact with other databases, you will see the cross-origin-duplicated databases.
Based on our observations, if a database is deleted, all related cross-origin-duplicated databases are also deleted. However, there seems to be an issue when developer tools are opened and a page refresh happens. On every page refresh, all databases are duplicated once again and seem to become independent from the original databases. In fact, it’s not even possible to delete these duplicated databases by using the regular indexedDB.deleteDatabase() function.
The only real protection is to update your browser or OS once the issue is resolved by Apple. In the meantime, we hope this article will raise awareness of this issue.