Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: TanStack Start authorization and RBAC, a developer's guide for 2026
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- 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.
Questions worth separating out
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 role checks break down in multi-tenant applications?
A: Role checks break down when access depends on both the user’s role and the active organisation or resource.
Q: What do security teams get wrong about route-level authorization?
A: They often treat route guards as if they were the security control, but they mainly shape the user experience.
Practitioner guidance
- Move authorization into server-side middleware Treat every createServerFn handler as a protected endpoint and enforce the permission check before business logic runs.
- Scope every decision to the active organisation Carry the current org in session context and verify that the target resource belongs to that org before updating, deleting, or returning sensitive data.
- Model permissions as resource-action pairs Use explicit permission names such as billing:write and users:delete so checks stay readable as the application grows.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The complete TanStack Start middleware pattern for session resolution and permission propagation through typed context.
- Code examples for organisation-scoped memberships, including how the active tenant is resolved on each request.
- Resource-level authorization logic for documents and projects, showing how ownership and hierarchy checks are structured in practice.
- The testing checklist for direct endpoint rejection, including allowed and denied server function calls.
👉 Read WorkOS's guide to TanStack Start authorization and RBAC →
TanStack Start authorization: are your server checks enough?
Explore further
22/06/2026 11:10 am
Server-side authorization is a governance boundary, not a UI pattern: The article correctly separates presentation checks from enforcement checks, and that distinction matters because access decisions only exist where the action can actually execute. This is the same control boundary identity teams should recognise in every application architecture, whether the actor is a human, service account, or API caller. The practitioner conclusion is simple: if the server can be called directly, the server must decide.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, which means access decisions can remain valid long after the business context has changed.
A question worth separating out:
Q: How can organisations test whether authorization is actually working?
A: They should test the deny path as carefully as the allow path. That means calling server functions directly, checking cross-tenant access attempts, and confirming that invalid role contexts are rejected before any data changes occur. If only the UI is tested, the boundary is not proven.
👉 Read our full editorial: TanStack Start authorization needs server-function checks, not route guards
