supabase.auth.getSession insecure warning on the server

[lorikku]

I keep getting the warning in my console. Is what I'm doing really insecure?

In my Next.js project, I use middleware.ts which checks if the user is logged in for every request sent to the server using supabase.auth.getUser. If no authentication exists, the user is redirected to the login page.

Now I still need the user's id and email and so forth on other server components on my website. This means I need to use supabase.auth.* to get this information.

My concerns:

• getUser calls Supabase, which takes extra time.
• getUser gives me (1) the user data and (2) verifies authentication
• Since (2) authentication was already verified in my middleware.ts, theoretically I only need (1) the user/current session data at this point.

My questions:

1. Why should I still use getUser over getSession at this point? If it means I can skip multiple authentication checks for a user who's already been successfully authenticated? And if I just need the session & user data?
2. Isn't 'session tampering' also protected 'by default', thanks to the usage of JWT tokens to store the user data? I pasted the JWT token from my cookies onto https://jwt.io/ and I saw that all my data was included IN the token, meaning it cannot be tampered with, right?

Please enlighten me!

Off-topic: I'm also thinking theoretically I could even further reduce the amount of auth requests by just validating the JWT cookie on MY Next.js server instead of calling Supabase auth remotely every time, and only calling them when I need a fresh token/auth.

[GaryAustin1]

This is the best discussion on it. https://github.com/orgs/supabase/discussions/23224

If you rely on RLS and not your server then you can generally pass on the session and RLS will protect you.
If you use on the server then you need getUser or to decode the JWT yourself with the JWT secret to insure it is valid. They are working on a new JWT method mentioned in that link to make the decode easier.

[lorikku]

So bottom line the moment you use getSession you cannot verify that the data is trustworthy.

The only trustable content is from the output of getUser or if you decode it yourself.

[GaryAustin1]

See my edit. If you did getUser you verified the JWT in the process.

[lorikku]

Yes but subsequent eg. client-side calls can also not be trusted with session because the JWT could still be tampered with afterwards.

But using RLS you mentioned earlier that it should be safe. Does that mean that any RLS calls also validate the JWT before proceeding?

If that's the case, and I am using RLS, then I shouldn't be worried any time I use browser or server client right? As long as I don't use admin client (secret key) without calling getUser (verifying) and my RLS policies are set up correctly.

[GaryAustin1]

You do not need to do anything to verify the session or JWT if you are just sending it to Supabase. It has to verify the JWT on each call (right secret, not expired) as it could be coming from a browser.

[lorikku]

Alright thanks! I think I understand it enough to know not to use session as a trustable source. Thanks sm for your time and effort to make me understand.