Verify session tokens before trusting server-side identity

[ericzakariasson]

Summary

Two auth hardening fixes. The Community Plugins MCP server (#453) builds on these, but they stand on their own and should merge first.

1. Server-side identity now comes from verified token claims

getSession() in apps/cursor/src/utils/supabase/auth.ts returned the session straight from the auth cookie. supabase.auth.getSession() does not check the access token's signature. So every server-side owner and admin check trusted unverified cookie contents: authActionClient, adminActionClient, /admin/plugins, and the edit pages. Several of those actions then write with the secret-key client, which bypasses row-level security.

getSession() now calls supabase.auth.getClaims(), which verifies the JWT against the project's JWKS (or asks the Auth server when the project uses symmetric keys). It builds the user from sub, email, and user_metadata.

• Callers only read session.user.id, plus email and user_metadata in safe-action.ts, so no call sites change.
• Client components keep using the browser getSession() for UI gating. That is fine because the server enforces everything.

2. /auth/callback only redirects within the site

The callback appended the raw next query parameter to the base URL. next=@evil.example therefore produced http://host@evil.example/, sending users off-site after they signed in. next is now resolved against the request origin, and anything that would leave the origin falls back to /.

Verification (local Supabase stack + bun dev)

• Forged auth cookie, before this change: /admin/plugins rendered the moderation queue, and approvePluginAction published a hidden plugin.
• Forged auth cookie, after this change: the action fails with Session not found!, the plugin stays hidden, and /admin/plugins renders no queue data.
• Real sessions: a member gets Unauthorized: admin access required. An admin still sees the queue and can approve.
• Real PKCE magic-link login through /auth/callback:
  • Before: next=@evil.example redirected to http://localhost:3000@evil.example/.
  • After: @evil.example → /@evil.example, //evil.example → /, and /plugins/acme-rules is preserved.
• bunx biome ci . and bun run typecheck pass. The remaining Biome warnings already existed in files this PR doesn't touch.

Notes

• If production still uses the legacy symmetric JWT secret, getClaims() makes one Auth server call per server-side session read. With asymmetric signing keys it verifies locally against a cached JWKS.
• Vercel preview: the deployment check fails, but it has failed on every main commit since Add admin moderation actions to the plugin detail page #434 (Sep 11). This PR doesn't cause it, but it blocks deploying this fix until someone checks the Vercel build logs.

  

---

Note

High Risk
Touches authentication and authorization paths; behavior changes for forged cookies and redirect handling, though the intent is security hardening.

^{Reviewed by Cursor Bugbot for commit e437a94. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cursor-directory	Ready	Preview	Oct 15, 2026 12:40am UTC

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Expired tokens crash session reads
  • Reproduced that the no-argument getClaims() in the locked auth-js 2.105.4 throws a raw Error('JWT has expired') out of getSession() when the cookie session's expires_at is null or still in the future but its access token has expired, so getSession() now catches any throw from getClaims() and returns null, with createClient() left outside the catch so Next.js cookies() errors still propagate.

Or push these changes by commenting:

@cursor push cc5236ce0a

Preview (cc5236ce0a)

diff --git a/apps/cursor/src/utils/supabase/auth.ts b/apps/cursor/src/utils/supabase/auth.ts
--- a/apps/cursor/src/utils/supabase/auth.ts
+++ b/apps/cursor/src/utils/supabase/auth.ts
@@ -19,7 +19,11 @@
  */
 export async function getSession(): Promise<VerifiedSession | null> {
   const supabase = await createClient();
-  const { data, error } = await supabase.auth.getClaims();
+  // getClaims() throws, instead of returning `error`, for some unverifiable
+  // tokens (e.g. an expired one whose session `expires_at` hasn't passed).
+  const { data, error } = await supabase.auth
+    .getClaims()
+    .catch((error: unknown) => ({ data: null, error }));
 
   if (error || !data?.claims.sub) {
     return null;

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 604eb26. Configure here.}