-
-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We cannot trust session.user
on the client side
#935
Comments
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. |
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.
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 |
Bug report
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.
base64-
prefix from the valuesession.user.id
with the victim's user id.base64-
session.user.id
. The victim user's data will be revealed.Additional Context
https://github.com/orgs/supabase/discussions/23224
The text was updated successfully, but these errors were encountered: