Fix trusted header auth bypass

[cursor]

Bug and Impact

Server-side auth helpers trusted incoming x-user-id / x-user-email request headers. Because proxy only sets those values on the response, a client could spoof them on Server Action requests and cause user-scoped account/trade/import paths to run as another user, or spoof subscription email checks.

Root Cause

getUserId() and subscription lookup treated middleware response headers as if they were trusted forwarded request headers.

Fix

• Derive getUserId() and getUserEmail() from the Supabase session only.
• Update subscription lookup to use the trusted email helper.
• Add regression tests proving spoofed headers are ignored.

Validation

• npx vitest run server/auth.test.ts
• npm run typecheck

  

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
deltalytix	Ready	Preview, Comment	Jun 22, 2026 7:10am

[github-actions]

🤖 Automated Code Review

No critical issues found in the diff. The main change in server/auth.ts is a solid security improvement: it stops trusting x-user-id and x-user-email request headers and derives identity directly from Supabase instead, which closes an obvious header-spoofing path. The new tests in server/auth.test.ts cover that regression well.

One non-critical concern is performance: getUserId() and getUserEmail() now always call supabase.auth.getUser(), so any hot path that invokes them repeatedly in one request will pay for extra auth roundtrips. That tradeoff is probably acceptable for security, but it may be worth caching the resolved user per request if these helpers are called multiple times in the same action.

Code quality is otherwise good. Error handling is consistent with the existing auth helpers, and server/subscription.ts now correctly depends on the trusted auth source instead of proxy headers. The only small TypeScript nit is the continued use of catch (error: any) in server/auth.ts; unknown would be safer, but this is not a blocker.

---

Generated by Cursor CLI workflow — e8c3c580300137df5073e7856ea0c8e4096e02ef Fix trusted header auth bypass · 2 review(s) remaining