2

I was recently having an argument with another programmer mate of mine regarding storing Firebase Auth UID (just the uid nothing else) in a cookie with sameSite: 'strict' enabled.

What's the argument about

Currently, I am working in a Nuxt JS project where I am saving the user's uid on onAuthStateChange() event in a cookie with sameSite: 'strict' enabled so that I can grab it in my serverMiddleware code and do stuff with it.

I have checked this firebase doc about managing cookie and it shows how to store the JWT idToken in a cookie and then in the server decode it.

In fact, that is who I initially coded my work. But due to some requirements, it was super helpful if I store the uid instead. So, I did that. Then I started reading about how can I hack my own data to see if anyone can harm my data from the uid in the cookie.

Then I stumbled upon to this firebase doc: Use the Cloud Firestore REST API which shows how to get the firestore data using REST API and I figured out that you need to provide Google OAuth 2.0 token in the header of the API call in order for it to work, otherwise even if you put the correct URL with all the collection name and everything (which is hard for an outsider to know, but lets assume he knows), you will get nothing but this:

{
  "error": {
    "code": 403,
    "message": "Missing or insufficient permissions.",
    "status": "PERMISSION_DENIED"
  }
}

I have also tried to run code in browser console in order to hack the data out of my project. But That didn't work as well.

Now in order to get the Google OAuth 2.0 token, the person must need login access to my account which is not that easy as I have a unique long password along with 2 Step Authentication with phone OTP & push notification. Besides if anyone has login access to my Google account, he can easily go to console.firebase.com and see the data, so at that point, nothing will matter.

But I did say that if anyone is using firebase Realtime database then I will not recommend storing the uid in a cookie as the realtime database provides easy REST API without any authentication layer to fetch data. At that time I would recommend using JWT idToken instead.

So, what's the final question?

The final question is this:

If someone is using firebase auth & firebase cloud firestore (not realtime database) using firebase SDK in his project, is it secure to store just the uid in cookie instead of storing JWT idToken if it will reduce the code complexity and code execution time over using idToken?

I would love to know your thoughts on these as there are many super experienced devs beside two programmers arguing.

My friend keeps telling me that storing uid in the cookie is not sure, but when I asked him why exactly, he had no concrete answer. As what is secure and what is not a universal thing and changes as you change your tools. But in this exact context what do you guys think? I know that normally in most cases it is not a secure thing, but I am asking about this specific context only.

iSaumya
  • 1,503
  • 5
  • 21
  • 50
  • You say "so that I can grab it in my serverMiddleware code and do stuff with it". Whether this is secure depends on the "stuff" you do with it. But if that stuff uses the UID as the sole means to identify the user as being authenticated, it is indeed not secure, as anyone can put any UID in such a cookie. I highly recommend shortening your question considerably (we have little interest in your friend's opinion, since they're not asking a question), and focusing on what you actually do with that UID, and what specific risk you're worried about. – Frank van Puffelen Oct 19 '19 at 18:43
  • Hi, thanks for the comment. Let's say I simply do a firestore db get request in my serverMiddleware. The attach that data to req and get it on my front end. I am not checking user authentication in server. I simply wanna pull some data from db of user is logged in. So here if user logged in the uid cookie exists and I do the firestore call. Now what do you think? Also sorry for the long question. Was just covering all ground. – iSaumya Oct 19 '19 at 19:03
  • 1
    There is nothing insecure about storing the UID in a cookie, nor in reading that cookie in your middleware. But if your middleware then assumes that the UID is the authenticated user, you have a security risk. What is keeping any other user from putting your or my UID into that cookie, and thus getting access to your or my data? – Frank van Puffelen Oct 19 '19 at 19:08
  • But how will anyone else will know anyone else uid? It's a random string given by firebase? I mean I got your point theoretically. But just trying to understand how is it practically possible? – iSaumya Oct 19 '19 at 19:11
  • 1
    If you surface a UID anywhere else in the code of your app (which is very common), anyone can pick it up and start passing it around. The string itself doesn't have any data, but if you expose mechanisms to work with that UID, as Frank suggested, you are essentially allowing anyone to use those mechanisms with any UID they know. – Doug Stevenson Oct 19 '19 at 20:10
  • 1
    It is in fact fairly common to expose the UID of a user to other user to identify that user. See https://stackoverflow.com/questions/37221760/firebase-is-auth-uid-a-shared-secret Also note that UIDs don't change over time, so if ever one (even inadvertently) leaks, you could impersonate that user forever. ID tokens on the other hand have a limited lifespan (currently about an hour), which limits the risk if they accidentally get exposed. – Frank van Puffelen Oct 19 '19 at 20:46
  • Thank you so much @FrankvanPuffelen & Doug for the explanation and insight. Really can't thank you enough for clearing my doubts. ♥ – iSaumya Oct 20 '19 at 05:50
  • Hey, sorry guys I just got another weird question in my mind. If I store the JWT in the cookie and then someone copies the JWT and paste it in something like https://jwt.io/ then he can see all the data of the JWT. So, is this secure? – iSaumya Oct 20 '19 at 06:32

1 Answers1

3

It is in fact fairly common to expose the UID of a user to other user to identify that user. See Firebase - Is auth.uid a shared secret?

There is nothing insecure about storing the UID in a cookie, nor in reading that cookie in your middleware. But if your middleware then assumes that the UID is the authenticated user, you have a security risk.

What is keeping any other user from putting your or my UID into that cookie, and thus getting access to your or my data?

Also note that UIDs don't change over time, so if ever one (even inadvertently) leaks, you could impersonate that user forever.

ID tokens on the other hand have a limited lifespan (currently about an hour), which limits the risk if they accidentally get exposed.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thank you so much for the response. Just one question, even the JWT idtokens can be copied from the cookie and then use something like jwt.io to read it's data. But yes no one can pretend to be some else. But what is your thoughts on reading the jwt token data? No way to safeguard that data? – iSaumya Oct 20 '19 at 16:37
  • Also one more thing, I am using `addAuthTokenListener()` in my project but I couldn't find any proper docs for that function in firebase auth docs. Just wanted to let you know as you work at Firebase. – iSaumya Oct 20 '19 at 16:44