We cannot trust session.user on the client side

[j4w8n]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Using data from session.user to render user information is just as insecure on the client side as it is on the server side.

This is because an attacker can signup for an account, login, then change the value of session.user.id in their own cookie, then make a request to the vulnerable app page.

To Reproduce

As with the server side vulnerability, this one also relies on an attacker knowing the Supabase user id of the targeted victim user.

1. Login to an app
2. Copy the value of your own auth token
3. Remove the base64- prefix from the value
4. Decode the value to get the session
5. Replace session.user.id with the victim's user id.
6. Base64 encode the tampered session and prefix it with base64-
7. Copy the value back into your cookie.
8. Go to a page that renders sensitive user data based on session.user.id. The victim user's data will be revealed.

Additional Context

https://github.com/orgs/supabase/discussions/23224

[retr0cube]

How can this be mitigated?

[j4w8n]

How can this be mitigated?

The only way I know of, for now, is to call getUser and use the user id from its returned data.

[J0]

Hey @j4w8n,

Thanks for flagging this again. Agree that this should be guarded against and I think [similar safeguards as described in the earlier thread would apply(https://github.com/orgs/supabase/discussions/23224#discussioncomment-9218731) (e.g. take extra care when using the secret to make verifications so that the attacker can't successfully act on 4 and 5.

4. Decode the value to get the session

5. Replace session.user.id with the victim's user id.

We are releasing asymmetric JWTs quite soon though. As with the thread that will likely help since it would take both the public key and the private key to decode, replace, and encode a new payload. The private key would be less likely to be available in this case.

Let us know if there are additional concerns that aren't addressed with asymmetric keys or any immediate pressing concerns