Topic starter
22/06/2026 10:19 am
TL;DR: TanStack Start route guards protect the user experience, but server functions remain callable directly unless authorization is enforced inside the handler path, according to WorkOS. The real security boundary is the server function, and that assumption should shape every RBAC design, test, and tenant-scoping decision.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “TanStack Start authorization and RBAC: A developer's guide for 2026”.
Key questions
Q: How should teams enforce authorization in TanStack Start applications?
A: Teams should enforce authorization inside server-side middleware and handler paths, not only in route guards or UI controls.
Q: Why do route guards fail to stop unauthorized server function calls?
A: Route guards only control which UI paths a user can reach.
Q: What breaks when tenant scope is not checked inside the handler?
A: Without a tenant-scope check, a user who is valid in one organisation can potentially read or modify data belonging to another organisation if the request reaches the wrong resource.
Practitioner guidance
- Enforce authorization in every server function Treat createServerFn handlers as the security boundary and place permission checks inside the handler path before any sensitive operation runs.
- Model permissions as resource:action pairs Replace broad role flags with discrete permissions such as users:delete and billing:write so handlers can test exact capabilities at runtime.
- Scope every request to the active organisation Verify the session’s org context against the target record or membership before modifying tenant data, and return Not found when the resource is outside scope.
Bottom line: TanStack Start authorization must be enforced in server functions because route guards only affect user experience, not endpoint access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 11:10 am
Server functions, not routes, define the effective security boundary in modern React frameworks: Route guards are a user experience control, but the callable handler is where authorization is actually decided. That distinction matters whenever the same endpoint can be reached without rendering the protected page. Practitioners should treat the handler path as the authoritative enforcement point.
A question worth separating out:
Q: When should organisations move from RBAC to hierarchical authorization?
A: When they start creating roles that are really just combinations of resource, tenant, or team boundaries, or when customers ask for access that should apply only to one subtree. That is the point where hierarchy adds more value than another role variant. It preserves least privilege without multiplying exceptions.
👉 Read our full editorial: TanStack Start authorization needs server-function checks, not route guards