firebase / firebase/firebase-js-sdk

FR: avoid data leaks after `signOut()` when persistence is `LOCAL` (indexedDB)

Open
#7,307 5 comments 1 reaction 0 assignees View on GitHub
api: auth feature request
Dominant language
TypeScript
Stars
5.1k
Forks
1k
Avg merge
2d 21h
Merged PRs (30d)
37

Description

### [REQUIRED] Describe your environment

* Operating System version: MacOS Ventura
* Browser version: Chrome 113.0.5672.92
* Firebase SDK version: 9.15.0
* Firebase Product: auth

### [REQUIRED] Describe the problem

#### Steps to reproduce:

After user explicitly `signOut()`, anyone can inspect Dev Tools Application tab and check previous user's Auth infos IN CLEAR. Even though those information are deemed as "safe" and "public" in the docs, it might be misinterpreted. In fact, even though `accessKeys` are technically revoked at signOut, still some other information are private. For instance, `displayName`, `photoURL`, `email`... are actual user's private information. But maybe even more important, Firebase Auth allows use of `customClaims` that could potentially be sensitive information we might not want to survive after `signOut()`.
Note: I am aware of the possibility to choose another persistence mode like `session` or `none`, but those also involve other User Experiences like for instance not being able to have 2 tabs signed-in, or lose session after refresh etc... But when using the standard `LOCAL` persistence, indexedDB is most usually used and this is totally fine to keep data stored indefinitely (and subject to the same leaks I just pointed out). However, I would argue that when the user clicks the button to `signOut()`, he'd think that no private data associated with him are still persisted. Finally, I am quite not any expert on the matter but, is that technically EU's GPDR compliant?! Maybe if some info is given beforehand but that would be better, IMHO, to just enforce clearing private infos after `signOut()` rather than let each devs make the mistake of not informing the users that their personal information are stuck in the browser indefinitely.

#### Relevant Code:

Today I use this workaround:

```javascript
import { initializeApp, getAuth, signOut } from "firebase/auth";
const app = initializeApp(firebaseConfig);

function logOff(){
singOut();
window.indexedDB.deleteDatabase(getAuth(app).persistenceManager.persistence.db.name);
}
```
Obviously this is not a sustainable solution as maybe db's name will not be stored in `.persistenceManager.persistence.db.name` in the future... But that's what I got so far.

Hence my proposal to just include the deletion as part of `signOut()` mechanism, but I can understand that it could be considered a breaking change (even though I would argue this is a security and personal data leak issue), maybe we could just have a cleaner proper method to clear persistence manually? Maybe something like this:
```javascript
import { clearAuthPersistence, signOut } from "firebase/auth";

function logOff(){
singOut();
clearAuthPersistence();
}
```
under the hood, `clearAuthPersistence` would just do an `window.indexedDB.deleteDatabase` but with proper handling of the database name.

But also why not just the other way around and have `signOut()` mechanics also clear persistence, but let an option to opt-out of this behaviour, like: `signOut({clearPersistence: true})`.

What do you think?! :)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.