What Happened
A multi-tenant enterprise SaaS application was tested using Evo Continuous Offensive Security, an AI-driven penetration testing platform. It identified 33 vulnerabilities that existing security controls missed. These were not simple injection flaws or misconfigurations but complex authorization bypasses and business logic vulnerabilities in the app's multi-tenant architecture.
The application had passed traditional Dynamic Application Security Testing (DAST) scans and annual penetration tests. Yet, critical flaws remained, exposing tenant data to potential cross-account access.
Timeline
Pre-deployment phase: Standard DAST tools scanned the application during CI/CD. No critical findings blocked release.
Annual pentest window: Human penetration testers focused on authentication flows, common injection points, and known attack patterns. They reported several medium-severity issues.
Continuous testing period: Evo COS ran autonomous testing cycles over several weeks, analyzing API behaviors, tenant boundaries, and business logic flows. It identified 33 vulnerabilities, including authorization bypasses that could allow one tenant to access another tenant's data.
Post-discovery: Development teams addressed the findings, but the incident raised questions about why existing security controls failed to catch these issues earlier.
Which Controls Failed or Were Missing
Insufficient authorization testing depth. Traditional DAST tools checked for authentication but didn't verify if authorization logic correctly enforced tenant boundaries across complex workflows. They sent payloads to endpoints but didn't model the business logic that determined access conditions.
Limited test coverage of business logic. Annual pentests allocated 40-80 hours of human time. Testers focused on OWASP Top 10 categories and known attack patterns. They didn't have time to map every API endpoint, understand multi-tenant data flows, or test authorization boundaries across all user role combinations.
No continuous validation. Security testing occurred at discrete intervals: during CI/CD (DAST) and annually (pentest). Between these points, code changes introduced new vulnerabilities. Multi-tenant authorization logic is complex, and small changes to one endpoint can create authorization bypasses elsewhere.
Lack of context-aware testing. DAST tools don't understand business context. They can't infer that "if a user creates a resource in tenant A, they shouldn't be able to modify that resource by changing the tenant_id parameter to tenant B." That requires understanding the application's intended behavior, not just its technical implementation.
What the Relevant Standard Requires
OWASP ASVS v4.0.3 addresses authorization testing directly:
- Requirement 4.1.1: "Verify that the application enforces access control rules on a trusted service layer."
- Requirement 4.1.3: "Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization."
- Requirement 4.2.1: "Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records."
Multi-tenant applications must test authorization at the business logic level, not just at the authentication layer.
PCI DSS v4.0.1 Requirement 6.4.2 states: "For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks." The standard explicitly requires continuous protection, not just point-in-time testing.
SOC 2 Type II Common Criteria CC6.6 requires: "The entity implements logical access security measures to protect against threats from sources outside its system boundaries." For SaaS applications, tenant isolation is a logical access control. If authorization bypasses exist, you're not meeting this criterion.
The Five Eyes Alliance recently warned that AI will bypass cybersecurity in months, not years. This isn't a future threat. It's happening now. If your testing methodology can't identify complex authorization flaws, you're not meeting the intent of these requirements.
Lessons and Action Items for Your Team
Stop treating authorization as an authentication problem. Your application probably has solid authentication. The issue is what happens after login. Map your authorization model explicitly: which roles can access which resources under which conditions? Document the rules. Test against them.
Test business logic, not just technical vulnerabilities. OWASP Top 10 coverage is necessary but insufficient. For multi-tenant applications, create test scenarios that verify:
- Tenant A cannot access Tenant B's data by manipulating IDs
- Role-based access controls work across all endpoints, not just the UI
- Cascading permissions behave correctly when resources reference other resources
Implement continuous testing. Annual pentests find what's broken today. They don't catch what breaks next Tuesday after a deployment. You need testing that runs continuously and adapts as your application changes. This doesn't replace human pentests. It fills the gaps between them.
Verify your DAST tool's coverage. Run a simple experiment: create a test endpoint that requires authorization. Give it a vulnerability where changing a user_id parameter grants access to another user's data. Does your DAST tool find it? Many won't, because they don't understand the business logic of "this user_id should match the authenticated user."
Document your tenant isolation model. For every API endpoint that handles tenant-specific data, document how tenant isolation is enforced. Is it in the query? The authorization middleware? The database schema? If you can't explain it clearly, you can't test it systematically.
Track authorization findings separately. In your vulnerability management system, categorize authorization flaws distinctly from other vulnerability types. This lets you measure whether your testing methodology is actually finding these issues. If you're not tracking authorization bypasses, you're probably not finding them.
The 33 vulnerabilities found in this single application aren't exceptional. They're typical of what happens when security testing focuses on technical vulnerabilities while ignoring business logic. Your application likely has similar issues. The question is whether you'll find them before someone else does.
