Cross-tenant resource access is blocked
Why it matters
IDOR (Insecure Direct Object Reference) in multi-tenant APIs is CWE-639 and CAPEC-122: an attacker increments or guesses a resource ID and retrieves a resource that belongs to a different tenant. The assumption that a valid UUID implies authorization is the root cause — valid IDs are observable (from your own data, from shared links, from support interactions) and UUIDs are not as unguessable as developers assume when millions exist. OWASP A01 classifies IDOR as one of the most prevalent and impactful web vulnerabilities.
Severity rationale
High because resource IDs can be observed through normal product usage, making cross-tenant access exploitable by any authenticated user without brute force.
Remediation
Include the tenant scope directly in the database lookup predicate so the database enforces ownership — never fetch then check:
// Vulnerable — fetches any tenant's document:
const doc = await db.document.findUnique({ where: { id: params.id } })
if (!doc) return notFound()
// Secure — returns nothing if the doc belongs to a different tenant:
const doc = await db.document.findFirst({
where: {
id: params.id,
organizationId: session.user.organizationId
}
})
if (!doc) return new Response('Not found', { status: 404 })
Use findFirst with both conditions rather than findUnique with just the ID. Apply this pattern in every [id] dynamic route under src/app/api/.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Multi-Tenancy Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-639 — Authorization Bypass Through User-Controlled Key
- cwe · CWE-285 — Improper Authorization
- owasp:2021 · A01 — Broken Access Control
- capec · CAPEC-122 — Privilege Abuse
Taxons
History
- 2026-04-18·v1.0.0·Initial import from saas-multi-tenancy·automated