Session tokens stored in localStorage in Supabase

Use the cookie helpers in Supabase's Next.js server-side auth guide when the server needs to see the session. @supabase/ssr stores the access token and the refresh token in cookies. Those cookies are not HttpOnly. The advanced SSR guide says both tokens are meant to be read by the browser, because the browser needs the refresh token to keep the session. Script on the origin can still read them. A cookie that script cannot read is a server-only session, the backend-for-frontend in the OWASP session sheet. Create the server client from the request cookies inside the Route Handler or Server Action. Do not persist the access token with localStorage.setItem, and do not describe the SSR cookies as the HttpOnly fix.

The publishable key may live in the browser. The user's access token and refresh token ride in the cookies that package writes, and those cookies stay readable by script. The Next.js server guide says not to trust getSession() in server code, including Proxy, because it reads the cookie without revalidating it. getClaims() verifies the token signature and expiry. On projects with asymmetric signing keys, the default for new projects, it verifies locally against a cached copy of the project's public keys. On projects still using a symmetric secret, it calls the Auth server instead. The advanced guide says that check does not notice a revoked session: an unexpired token stays valid to getClaims(). Call getUser() where rejecting the session after logout matters.