getAuthenticatorAssuranceLevel() triggers "getSession() could be insecure" warnings

[sleepdotexe]

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

Despite not using getSession() anywhere in my code, I am still receiving (numerous) console warnings stating the following:

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 many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.

After doing some investigation, this issue seems to only occur when checking the user's MFA status via supabase.auth.mfa.getAuthenticatorAssuranceLevel(). If I remove or replace this call with a static return of 'aal2' values, the warnings disappear in console.

I am using Next.js and server-side rendering with the App router + supabase/ssr.

To Reproduce

1. Follow the guide to set up supabase in a Next.js project as per the docs here.
2. Add a function that performs server-side MFA validation as per the docs here.
   • This function should be run on the server (eg. Server component) and call supabase.auth.mfa.getAuthenticatorAssuranceLevel().
   • In my implementation, the currentLevel property of this call is compared against the defined/expected AAL level for that route, then - if they don't match the expected level` redirects them to the appropriate page (login page, enter MFA code page, dashboard page)
3. Call/await this function in a page or layout.
4. Run the app and then visit a page where this function is called.

Expected behavior

Since I have not called/used getSession() anywhere, I should not be seeing warnings in the console about getSession().

System information

• OS: Windows
• Browser: n/a
• Version of supabase-js: 2.43.1
• Version of @supabase/ssr: 0.3.0
• Version of Node.js: 20.9.0

Additional context

I did some investigation and it seems like getAuthenticatorAssuranceLevel() is referencing the session.user object in this line:

private async _getAuthenticatorAssuranceLevel(): Promise<AuthMFAGetAuthenticatorAssuranceLevelResponse> {
    return this._acquireLock(-1, async () => {
      return await this._useSession(async (result) => {
        // ...

        const verifiedFactors =
          session.user.factors?.filter((factor: Factor) => factor.status === 'verified') ?? []
               // ^----

Some suggestions/thoughts:

• Is getAuthenticatorAssuranceLevel() also meant to be treated as an insecure on the server (like getSession())? If so, this probably needs to be reflected more clearly in the docs to prevent a developer from trying to protect routes based only on MFA status (this is possible since a logged-out user would return null for currentLevel and nextLevel).
• Could the getAuthenticatorAssuranceLevel() be made more secure server-side by calling _getUser? Then the resulting value could be referenced as user.factors instead of session.user.factors. I assume this would add quite a lot of overhead to this function.
• If we don't want to force every implementation of getAuthenticatorAssuranceLevel() to call _getUser by default, could it be an option to pass a user to getAuthenticatorAssuranceLevel() so the developer can define if they want the method to be secure on the server?
• If none of the above is possible, at the very least the warning probably needs to be supressed for this method since it is confusing and irrelevant considering getSession() has not been used anywhere in the code.

I haven't explored too deeply into the source code so hopefully these thoughts make sense.

[kizivat]

There is a PR for that #909

[Collin0810]

Are there any updates on this? We are also using Next.js with the latest SSR package and implementing getAuthenticatorAssuranceLevel() in the middleware to check the users' AAL level. Our logs are flooded with warnings:

"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 many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server."

Which makes it really hard to debug and read console logs for anything (un)related to Supabase in our app.