Shared infrastructure, and a shared blast radius
Multi-tenancy means many separate customers' data and workloads run on the same underlying infrastructure, distinguished only by logical boundaries rather than physically separate systems. This is efficient, but it also means the isolation between tenants exists entirely in software — in query filters, in access checks, in scoping logic — rather than in something physically incapable of crossing over.
A single missing tenant filter on one query path, or one endpoint that trusts a client-supplied tenant identifier instead of deriving it from the authenticated session, is enough to let one tenant read or modify another's data. This class of bug is specific to multi-tenant systems and doesn't have an equivalent in a single-tenant deployment.
Isolation has to be enforced at every layer that touches tenant data
Because the failure mode is cross-tenant leakage rather than an outright outage, these bugs are also harder to notice in normal operation — everything appears to work, just for the wrong customer. Defending against this generally means deriving the tenant boundary from a source the caller can't override (an authenticated session, not a request parameter), and applying that boundary consistently at every layer that reads or writes tenant data, not just at the outermost API.
Testing specifically for cross-tenant access — deliberately trying to reach another tenant's resource with a valid session for a different tenant — catches a category of bug that ordinary functional testing, which by design tests within one tenant's data at a time, tends to miss.