next-auth: [firebase adapter] - Firebase adapter requires open security rules we cannot allow in production

Adapter type

@next-auth/firebase-adapter

Environment

System: OS: Windows 10 10.0.22000 CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor Memory: 9.27 GB / 31.95 GB Binaries: Node: 16.13.2 - C:\Program Files\nodejs\node.EXE Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD Browsers: Edge: Spartan (44.22000.120.0), Chromium (103.0.1264.62) Internet Explorer: 11.0.22000.120 npmPackages: next: ^12.2.3 => 12.2.3 next-auth: ^4.10.2 => 4.10.2 react: 18.2.0 => 18.2.0

npmPackages: @next-auth/firebase-adapter: ^1.0.1 => 1.0.1

Reproduction URL

https://github.com/nextauthjs/next-auth-example

Describe the issue

Firebase adapter is using client side library and it is expecting the security rules to be open for it to edit sessions, accounts and other collections managed by it. We cannot allow those collections to have an open security rule.

Is there a way we can safely open security rules for the firebase adapter to write and access these files as part of user context ensuring that a malicious user cannot access the records.

eg:

match /users/{uid} {
   allow read, write:  if request.auth.uid == uid;
}

match /sessions/{id} {
   allow read, write:  if request.auth.uid == resource.data.userId;
}

match /accounts/{id} {
  allow read, write: if request.auth.uid == resource.data.userId;
}

I tried a few with no luck. If you have the documentation for the rules the adapter is very viable to be used in production and would solve a lot of manual work that need to be done.

The ideal fix here would be move the firebase adapter to require to use firebase-admin package as it would then have the right permissions without us opening the security rules.

Great work on the adapter !


How to reproduce

Setup the adapter and lock down security rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Expected behavior

We should have a clear security rule setup ensuring there is no security vulnerabilities exposed by opening up permissions.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 14
  • Comments: 15 (2 by maintainers)

Commits related to this issue

Most upvoted comments

+1 to firestore-adapter accepting instance of firebase-admin

firebase-admin is already required server-side to createCustomToken(), so passing it to the adapter would be natural

Not the ideal approach, but the following Cloud Firestore Security Rule works. Just make sure that you don’t expose Firebase config on client side code.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
    match /users/{document} {
    	allow read, write: if true;
    }
    match /sessions/{document} {
    	allow read, write: if true;
    }
    match /accounts/{document} {
    	allow read, write: if true;
    }
    match /verificationTokens/{document} {
    	allow read, write: if true;
    }
  }
}

Since the adapter is being used server-side only, you should be safe as users cannot interact with the database directly. 🤔 cc @chanceaclark

I don’t think we can use it server side with client side firebase config. If the Adapter is supposed to be used on the server side, it should accept the firebase-admin instance than the firebase instance.

As I mentioned opening up security rules for read and write true is extremely dangerous and should never be done on Firebase. It can lead to massive issues down the line. Check their security rules guidelines.

https://firebase.google.com/docs/rules/insecure-rules#open_access

I thought the same thing and came to this issue!

My product will use client-side firebase in Browser so it’s not realistic to hide firebase config.

The ideal fix here would be move the firebase adapter to require to use firebase-admin package as it would then have the right permissions without us opening the security rules.

I think so too. Using firebase-admin and serviceAccount private key is an ideal solution.

Looks like the thread stagnated, I will write another with firebase admin adapter this week send out a PR.

Since the adapter is being used server-side only, you should be safe as users cannot interact with the database directly. 🤔 cc @chanceaclark

Not the ideal approach, but the following Cloud Firestore Security Rule works. Just make sure that you don’t expose Firebase config on client side code.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
    match /users/{document} {
    	allow read, write: if true;
    }
    match /sessions/{document} {
    	allow read, write: if true;
    }
    match /accounts/{document} {
    	allow read, write: if true;
    }
    match /verificationTokens/{document} {
    	allow read, write: if true;
    }
  }
}

Those are not secure rules, if that is enabled your firebase can be compromised very easily. Remember even with public config a malicious user can delete all users and collections with these rules.

+1 here. This is not a secure setup.

I’ve created a version of the adapter that uses the Firebase server-side SDK. There is a PR incoming. Please let me know how you feel about it.

@balazsorban44 @Chibionos