Auth in middleware that skips API routes in Supabase

Inside the Route Handler or Server Action, create the Supabase client from that request's cookies so the query runs as the user and row level security applies. Supabase's Next.js server-side guide says SSR uses cookie-based session storage through @supabase/ssr, and that you create the server client per request because the cookies come from the request. Do not use a module-level secret-key client as the stand-in for a matcher that skipped /api. Supabase's API key guide says a secret key bypasses every row level security policy.

The same server guide says not to trust supabase.auth.getSession() in server code, including Proxy. It reads the session out of the cookie without revalidating it. Use getClaims(). That call verifies the token's signature every time. 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 SSR guide says this does not catch a revoked session: an unexpired token stays valid to getClaims(). Call getUser() where rejecting the session after logout matters.

The documented proxy refreshes the session cookie by calling getClaims(). That refresh does not run on a path the matcher skips, and refreshing a token is not the same job as rejecting a logged-out caller inside the handler the request actually hits.