The Challenge
The client operates a multi-tenant SaaS platform serving business customers who upload commercially sensitive data. The platform had grown quickly, its API surface had expanded well beyond what the original design anticipated, and enterprise prospects were beginning to ask harder questions during procurement than the company could confidently answer.
The specific worry was tenant isolation. In a multi-tenant architecture, the boundary between one customer's data and another's is enforced in application logic rather than by infrastructure, which means a single missing authorization check can expose it. Automated scanning had found nothing, but the engineering team understood that scanners do not reason about which user should be allowed to see which record.
Our Approach
StrikeCyber ran an authenticated penetration test against both the web application and the API, working from multiple accounts across separate tenants so that cross-tenant access could be tested directly rather than inferred.
- Authenticated testing from several user roles and two independent tenants, systematically attempting to reach objects belonging to the other.
- Full API surface enumeration, including undocumented and deprecated endpoints still reachable in the production build.
- Business logic testing across the workflows that mattered commercially: billing, entitlement, invitation and role assignment.
Testing followed the OWASP methodology and covered the web application and API surfaces together, because in a modern SaaS product the same authorization decisions are reached through both and the two are frequently inconsistent.
What We Found
- Broken object-level authorization. Several API endpoints validated that a caller was authenticated but not that the requested object belonged to the caller's tenant, allowing records to be read across the boundary by changing an identifier.
- A deprecated endpoint still live. An older API version, believed to have been retired, remained reachable and had none of the authorization improvements added in the current version.
- Privilege escalation through invitations. A user with a limited role could invite a new user at a higher role than their own, then use that account.
- Rate limiting applied inconsistently. Protection existed on the login endpoint but not on the password reset or invitation flows.
The Outcome
The team fixed the object-level authorization failures by moving the tenant check into a shared middleware layer rather than relying on each handler to implement it, which addressed the whole class rather than the four instances found. The deprecated API version was removed, the invitation flow was corrected to prevent role escalation, and rate limiting was applied consistently across every unauthenticated endpoint.
A retest confirmed the cross-tenant paths were closed. The company also gained a report it could put in front of enterprise prospects during security review, which shortened its sales cycle noticeably, and adopted authenticated testing as a release gate rather than an annual event.
Why It Matters
Broken object-level authorization is the most common serious flaw in modern APIs and the one automated tooling is least able to find, because a scanner cannot know that record 4021 belongs to a different customer. For a SaaS platform, tenant isolation is not one security control among many. It is the product promise, and the first enterprise customer to discover it is not held will be the last. To test your application and API properly, get in touch.