Supabase · sdk · fg-0197

Server logs fill with Using the user object as returned from supabase.auth.getSession() could be insecure

Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure

Verified 2026-10-15 · Confirmed by 0 builders · Trust 50/100

Cause

On the server, the session comes from cookies the client can forge, so the library wraps session.user in a proxy that warns on first access. Library internals and your own route guards that read session.user trigger it.

Fix

Use getClaims() to verify the JWT, or getUser() to ask the Auth server, whenever an identity decision is made on the server. Read only the access token from getSession, never the user object.

Apply

const { data, error } = await supabase.auth.getClaims();
if (error || !data) return redirect('/login');
const userId = data.claims.sub;

Affects: Server-side clients from @supabase/auth-js (gotrue-js) 2.63.0, released 2024-03-26, onward, as bundled in @supabase/supabase-js and used by @supabase/ssr

Sources

• https://github.com/supabase/auth-js/issues/873
• https://github.com/supabase/supabase-js/blob/master/packages/core/auth-js/src/lib/helpers.ts
• https://supabase.com/docs/reference/javascript/auth-getsession
• https://github.com/supabase/auth-js/releases/tag/v2.63.0

claude mcp add --transport http footgun https://getfootgun.com/api/mcp