Skip to content

The 3 Usecases

The Three Multi-User Testing Use Cases

Multi-user security testing can be systematically categorized into exactly three distinct use cases, each representing a fundamentally different testing objective. These use cases are mathematically comprehensive: they cover all possible combinations of user exploration requirements and permission symmetry. Escape has been architected to support all three scenarios by design.

When testing applications with multiple users, two critical dimensions must be considered:

  1. Exploration Coverage: Whether one or all users require full application crawling
  2. Permission Symmetry: Whether users possess equivalent or different privilege levels

These dimensions yield precisely three mutually exclusive scenarios that encompass all possible multi-user testing requirements.

Use Case 1: Independent User Exploration

Scenario: Complete application behavior analysis is required for multiple distinct user roles or personas.

When This Applies:

  • SaaS Platform Testing: A project management tool must be validated separately for Account Owners, Project Managers, and Team Members, as each role interacts with fundamentally different features and API endpoints.
  • Healthcare Systems: HIPAA compliance requires demonstrating that Physicians, Nurses, and Administrative Staff each have appropriately scoped access to patient records, with distinct workflows that must be independently verified.
  • E-commerce Marketplaces: Separate security validation is needed for Buyers, Sellers, and Marketplace Administrators, as each persona accesses different subsets of the platform.

Implementation:

Two or more scan profiles should be created, with each profile configured to perform complete crawling and security testing for a specific user. While the scans operate independently, issues discovered across multiple profiles are automatically deduplicated at the asset level. This ensures that common vulnerabilities appear only once in unified views such as "All Issues" or the "ASM Asset View," while role-specific vulnerabilities remain properly attributed to their respective user contexts.

Why This Is Required: Different user roles may expose entirely different API surfaces, authentication flows, and business logic. Independent exploration ensures comprehensive coverage of role-specific attack surfaces.

Use Case 2: Symmetric Permission Tenant Isolation Testing

Scenario: Validation of data segregation between accounts or tenants with equivalent permission levels is required.

When This Applies:

  • Multi-Tenant SaaS Applications: A CRM system must verify that Company A's sales representatives cannot access Company B's customer data, despite both having identical "Sales Rep" permissions within their respective tenants.
  • Financial Services Platforms: A banking API must ensure that customers with standard accounts cannot access transaction histories or account details of other standard account holders.
  • Educational Platforms: An LMS (Learning Management System) must validate that students enrolled in Course A cannot view submissions, grades, or personal information of students in Course B.

Implementation:

A single scan profile is configured with a primary user for exploration and crawling, while secondary users are designated as exploitation targets. Escape automatically tests for Broken Access Control (BAC), Tenant Isolation, and Cross-User Data Breach vulnerabilities by attempting to replay the primary user's requests with secondary users' credentials. Since permission levels are symmetric, authorization failures can only be detected in one direction.

Why This Is Sufficient: When users possess equivalent permissions, authorization violations are inherently bidirectional. Testing A→B access automatically validates B→A access constraints due to permission symmetry.

Use Case 3: Asymmetric Permission Bidirectional Testing

Scenario: Validation of authorization controls between users with different privilege levels, where authorization failures may occur in either direction.

When This Applies:

  • Enterprise Applications with RBAC: An admin console must verify both that Standard Users cannot access Admin endpoints, and that Admin accounts do not inadvertently leak Standard User private data through overly permissive queries.
  • Healthcare EMR Systems: Testing must confirm that Physicians cannot access Administrative billing records, while Administrators cannot view detailed clinical notes, despite both being "privileged" roles in different domains.
  • Financial Trading Platforms: Validation is required to ensure that Portfolio Managers cannot access Compliance Officer audit trails, while Compliance Officers cannot execute trades, representing distinct authorization domains.

Implementation:

Two separate scan profiles must be created to test both authorization directions:

  • Scan Profile A: User A is configured as the primary user for exploration, with User B designated as the exploitation target
  • Scan Profile B: User B is configured as the primary user for exploration, with User A designated as the exploitation target

This bidirectional testing approach ensures that authorization failures are detected regardless of which user is the attacker and which is the victim.

Why Both Directions Are Required: Asymmetric permissions create asymmetric attack surfaces. User A may have access to endpoints that leak User B's data, while User B may have access to entirely different endpoints that leak User A's data. Only bidirectional testing captures both vulnerability classes.