SaaS Platform Penetration Test

Overview

Background

A B2B SaaS company providing cloud-based project management software engaged Cyberlord ahead of enterprise procurement reviews and SOC 2 scrutiny. The platform served 50,000+ business users across 85 countries, with a public application, mobile clients, and partner integrations sharing one API layer. Buyers and auditors wanted proof that tenant data stayed separated in a shared cloud environment and that the public API could withstand realistic abuse. Internal testing existed, but it had not produced evidence the sales and compliance teams could show a customer security reviewer.

What made the platform difficult to test

Multi-tenancy set the tone for the engagement. Every object and endpoint had to enforce separation, and more than 200 endpoints supported web, mobile, and partner workflows. Weekly deployments meant access-control regressions could reach production quickly and quietly. Enterprise questionnaires asked for current third-party testing evidence rather than internal assertions. The client needed findings engineering could act on within its existing release cadence, not a document that waited for the next audit cycle.

Scope and rules of engagement

The engagement was a two-week black-box test of the external application. Written authorization defined the target tenants, test accounts, and endpoints in scope. Team members held accounts at standard, manager, and admin levels so authorization boundaries could be examined as a real user experiences them. Testing avoided destructive payloads and bulk data extraction; where a cross-tenant read was demonstrated, the team captured the minimum evidence needed to prove impact and stopped. Test windows were agreed in advance with an escalation contact available throughout.

Approach

Testing followed the product's own workflows. Registration, login, password reset, and session handling were reviewed first, then project, workspace, and attachment API routes, and finally CSV export, report generation, and file upload endpoints. Authorization received the most attention: direct object references, predictable identifiers, role boundaries between standard, manager, and admin users, and cross-tenant access attempts using manipulated requests. Resilience checks covered authentication throttling and lockout behavior, OAuth implementation and third-party token handling, and whether logging captured actions that matter during an investigation.

What the testing found

Twelve API issues were remediated in total, alongside one critical authorization flaw. A predictable object pattern allowed a crafted request to target resources outside the current tenant context; with the right sequence, project references could be enumerated and data belonging to other organizations retrieved. High-severity rate limiting gaps affected authentication endpoints, export and reporting paths, and upload endpoints, which did not share the main application's throttling standard. Medium findings covered OAuth state handling in one integration flow, scopes broader than necessary, and long-lived sessions without clear rotation and revocation rules.

Remediation support

Fixes were delivered with engineering rather than handed over as a list. Object-level authorization checks were added to sensitive API endpoints, and rate limits were aligned across authentication, export, and upload paths. The OAuth integration was corrected for state handling and given tighter scopes. Logging was extended to high-risk tenant and admin actions so investigations would have a record. Engineering also added pre-release security checkpoints for authentication, file upload, and access-control changes, which suited a weekly deployment model better than a periodic review.

Results

The client validated tenant isolation and closed the critical exposure before anyone else could reach it. Evidence from the engagement supported SOC 2 control narratives, remediation tracking, and auditor review. Security questionnaires became easier to answer because the team could point to a current third-party assessment. The most durable change was procedural: access-control and upload changes now pass through a checkpoint before production, addressing the regression risk that weekly releases had created.

Lessons for multi-tenant platforms

The pattern is consistent across multi-tenant products. Authorization must be tested per object and per role rather than assumed from a tenant identifier in a token. Rate limits belong on every endpoint that consumes resources, including exports and uploads that are often treated as internal features. OAuth scopes and session lifetimes deserve the same review as login logic. Most importantly, control must survive the release process, so testing should be paired with checkpoints that catch regressions between assessments.