logging: warning about insecure user object when using getClaims() in server-side context

[fable-coltish]

Problem Description

I'm receiving a warning when using supabase.auth.getClaims() in a server-side Next.js application, even though I'm not using the methods mentioned in the warning.

Warning Message:

Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and may not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.

My Implementation:

// Server-side Next.js action
const authResult = await ResultAsync.fromPromise(
  supabase.auth.getClaims(),
  (e) => createAppError(e, currentContext, 'supabase.auth.getClaims')
)

const { data, error } = authResult.value
if (error) {
  return err(createAppError(error, currentContext, 'supabase.auth.getClaims'))
}

const authUser = transformJwtClaimsToAuthUser(data?.claims ?? null)

Context

• I'm using getClaims() for server-side authentication in a Next.js 15.3.1 application
• My Supabase project is configured with asymmetric JWT validation
• I'm following the documented best practice of using getClaims() for performance benefits
• I am NOT using getSession() or onAuthStateChange() methods anywhere in my code

Questions

1. Is this warning a false positive? The warning mentions getSession() and onAuthStateChange(), but I'm only using getClaims(). Does getClaims() internally use these methods?

2. Should I ignore this warning? Given that getClaims() is documented as the recommended approach for server-side authentication with asymmetric JWTs, should I safely ignore this warning?

3. Is there a way to suppress this warning? For legitimate server-side usage of getClaims(), is there a way to suppress this warning?

Expected Behavior

I expect that using getClaims() in a server-side context with asymmetric JWT validation should not trigger warnings about insecure user objects, since:

• getClaims() performs server-side JWT signature verification
• It uses the public key for validation without network calls
• It's documented as the recommended approach for server-side authentication

Environment

• Framework: Next.js 15.3.1
• Supabase Auth: Latest version
• Context: Server-side authentication (Server Actions)
• JWT Configuration: Asymmetric JWT validation enabled
• Usage Pattern: Server-side only, no client-side auth code

Additional Context

I'm following the pattern described in the Supabase documentation for server-side authentication, specifically using getClaims() for its performance benefits with asymmetric JWT validation. The warning is causing confusion about whether this is the correct approach.

Related Documentation

• Supabase JWT Signing Keys Blog Post
• Supabase Auth getClaims Documentation

[gonchantech]

Hello, let me answer your questions.

1. Is this warning a false positive? getClaims() internally uses getSession(). In a server-side environment, cookies could potentially be tampered with, so the warning is essentially saying it’s unsafe to fully trust that data.

2. Should I ignore this warning? In your use case, it’s safe to ignore. The warning means that using the user object from getClaims() directly as the logged-in user could be unsafe, but since your purpose is to verify the user with getClaims(), this is not an issue.

3. Is there a way to suppress this warning? There is a flag called suppressGetSessionWarning, but it isn’t exposed in GoTrueOptions when instantiating the client, so it’s always set to false. I’m considering opening a pull request to make this configurable.

[mandarini]

I think this PR should have fixed this issue. It's available on the latest version of supabase-js. Can you please try it out? In the same time, we are working on updating our documentation.

Please keep an eye on this issue: https://github.com/supabase/supabase-js/issues/1709 And this issue: https://github.com/supabase/supabase/issues/40985

Once the documentation is complete, I will be closing this issue and the two above mentioned issues.

Thank you very much for your contribution and for raising this.