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.

Watch our Youtube overview

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:

Try the demo

The leak was reported to the WebKit Bug Tracker on November 28, 2021 as bug 233548.

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.

A short introduction to the IndexedDB API 

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.

If you want to learn more about how IndexedDB APIs work check out the MDN Web Docs or the W3C specification.

The IndexedDB leaks in Safari 15

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.

Why is this leak bad?

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.

How many websites are affected?

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.

We also saw a pattern where indexed databases named as universally unique identifiers (UUIDs) are being created by subresources, specifically ad networks. Interestingly, loading of these resources seems to be in some cases blocked by Safari’s tracking prevention features, which effectively prevents the database names from leaking. These leaks will also be prevented if the resources are blocked by other means, for example when using adblocker extensions or blocking all JavaScript execution.

Does Safari private mode protect against the leak?

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.

Demo

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.

Try the demo

Reproducing the leak

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. 

This behavior makes it very difficult to use the developer tools to understand what exactly is happening with the databases that a website interacts with. It is therefore recommended to use other means of debugging (for example rendering output into the DOM instead of using console logs or the JavaScript debugger) when trying to reproduce the leaks described in this article. 

How to protect yourself

Unfortunately, there isn’t much Safari, iPadOS and iOS users can do to protect themselves without taking drastic measures. One option may be to block all JavaScript by default and only allow it on sites that are trusted. This makes modern web browsing inconvenient and is likely not a good solution for everyone. Moreover, vulnerabilities like cross-site scripting make it possible to get targeted via trusted sites as well, although the risk is much smaller. Another alternative for Safari users on Macs is to temporarily switch to a different browser. Unfortunately, on iOS and iPadOS this is not an option as all browsers are affected.

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.