Cloud tenant isolation: Hiding other patients in the interface is not enough
Shared platforms need object-level authorisation and explicit isolation tests. Handle unexpected records without extending an exposure.
Editorial review:
Background & source findings
Multi-tenant services may share resources while logically separating customers. Every request must check whether a user can access the particular object. OWASP calls missing object-level checks Broken Object Level Authorization. [1]
Hidden buttons or hard-to-guess identifiers are not complete controls. Separate databases also do not guarantee safe search, export or support functions. Technical and organisational controls must work together. [1], [2]
Unauthorised exposure requires assessment. Article 33 GDPR governs regulator notification; Article 34 addresses affected people where high risk is likely. Notification conditions and automatic penalties are different matters. [3]
Scope & limitations
Multi-tenancy is not inherently unsafe, and this is not an allegation against a vendor. Do not test against other customers' production data without explicit authority.
In plain language
Fictional example: Two test tenants contain invented records. Authorised testers check searches, downloads and exports rather than approving isolation from the landing page alone.
Practical recommendations
Our recommendation: Ask for an explicit authorisation model and tenant-boundary test evidence. Cover APIs, background jobs, exports and administrative tools using an agreed scope and artificial records.
If unexpected real data appear, do not explore additional files. Stop unnecessary access and report securely to the provider and privacy team. Preserve only evidence needed under the agreed incident procedure; uncontrolled screenshots and forwarding can increase disclosure.