Notifications
Clear all
Topic starter
22/06/2026 10:20 am
TL;DR: TanStack Start treats server functions as the real security boundary, so a beforeLoad route guard alone cannot stop direct HTTP calls to sensitive endpoints, according to WorkOS. The key assumption that breaks is that protecting a route also protects the underlying operation; in this framework, it does not.
NHIMG editorial — based on content published by WorkOS: TanStack Start authentication, a developer's guide for 2026
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams enforce authentication in TanStack Start server functions?
A: Security teams should enforce authentication inside each server function or its middleware, because those functions are callable HTTP endpoints.
Q: Why do route guards fail to protect sensitive TanStack Start operations?
A: Route guards fail because they protect the rendered page, not the underlying endpoint.
Q: What do teams get wrong about cookie-based sessions in modern web apps?
A: Teams often treat a valid session cookie as proof that every downstream action is safe, but it is only identity context.
Practitioner guidance
- Enforce auth on every sensitive server function Verify the session inside each createServerFn handler or attached middleware before any read or write operation touches protected data.
- Separate route guards from endpoint controls Use beforeLoad only to redirect unauthenticated users and populate route context.
- Test direct HTTP calls to protected operations Send unauthenticated requests to server functions such as updateProfile or deleteAccount and confirm they fail without a valid session.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step TanStack Start auth patterns for login, logout, redirects, and protected layouts.
- Complete code examples for middleware, typed context, and cookie-backed sessions in server functions.
- Production checklist items for password hashing, rate limiting, cookie settings, and direct-call testing.
- Practical build-versus-buy guidance for teams deciding between custom auth and managed identity tooling.
👉 Read WorkOS's guide to authentication in TanStack Start →
TanStack Start auth: are route guards enough for server functions?
Explore further
22/06/2026 11:12 am
Route protection is not operation protection. TanStack Start exposes a boundary mistake that identity teams see in other systems too: the control that protects the interface is often not the control that protects the action. beforeLoad can keep unauthenticated users out of a page, but it cannot stop direct access to a callable server function. The practitioner lesson is that the security boundary must sit where the operation executes, not where the UI renders.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: How do route context and middleware work together in TanStack Start?
A: Route context carries typed user data into the page experience, while middleware enforces access before a server function executes. That split is useful because it separates navigation from authorisation. The right model is to let beforeLoad handle redirects and middleware handle the actual access decision.
👉 Read our full editorial: TanStack Start authentication: server functions are the boundary
