All packsMulti-Tenant Auth & RBAC CoreSolve
idor org id enumeration 403 vs 404 multi tenant saas
403 on a non-member request confirms the org exists
Returning 403 for both a nonexistent org and one you're not a member of lets an attacker enumerate real org ids by the response code alone.
What goes wrong
If a request for an org a user isn't a member of returns 403 (forbidden) while a request for a genuinely nonexistent org id returns 404, the status code itself becomes an oracle: an attacker can enumerate which org ids are real just by watching which ones come back 403 instead of 404, without ever seeing a byte of that org's actual data.
Why agents get it wrong
403 reads as the semantically correct HTTP status for "you don't have permission," and REST conventions generally teach 403-for-forbidden, 404-for-not-found as separate, independent rules -- treating them as one combined decision, specifically to avoid leaking existence, is a security-review-level insight that doesn't fall out of REST convention on its own.
What Multi-Tenant Auth & RBAC Core pre-decides
Core decision 18 collapses "org doesn't exist" and "org exists but you're not a member" into the same 404 -- org ids must not be enumerable. 403 is reserved specifically for "you are a member but your role is insufficient for this action," which only fires after membership is already established, so it never leaks whether a non-member's guess was a real org id.
Source: ARCHITECTURE.md core decision 18