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.

Understanding the Complete Landscape¶

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.

Tenant Isolation, Access Control, and Data Segregation Testing¶

Understanding API-Level Security Vulnerabilities¶

Tenant isolation and data segregation vulnerabilities are fundamentally API-level security concerns. Whether testing occurs through API DAST or WebApp DAST, the underlying vulnerabilities being detected originate from the API layer of the application architecture.

Why Isolation Is an API-Level Concern:

Modern applications are architecturally composed of presentation layers (web interfaces, mobile applications) and data access layers (REST APIs, GraphQL endpoints, RPC services). Data segregation is enforced at the API level through authorization logic that validates whether a given authenticated user can access a specific resource. When this authorization logic is absent, insufficient, or incorrectly implemented, the vulnerability exists within the API itself, regardless of which client interface is used to trigger the request.

A web application's UI may visually hide data that should not be accessible to a user, but if the underlying API endpoint returns that data without proper authorization checks, the vulnerability is present in the API. Similarly, a mobile application might not display certain features to unprivileged users, but if the API endpoints backing those features lack authorization enforcement, the security boundary has been violated at the API layer.

Configuration Support Across Testing Modes:

Escape's multi-user testing configurations are supported across both API DAST and WebApp DAST modes. However, the security issues identified—Broken Access Control (BAC), Tenant Isolation failures, Insecure Direct Object References (IDOR), and Cross-User Data Breaches—are invariably manifestations of API-level authorization deficiencies.

• API DAST: Direct testing of REST, GraphQL, SOAP, and other API protocols, where requests are constructed and sent directly to API endpoints
• WebApp DAST: Browser-based testing where user interactions generate API traffic, which is then intercepted, analyzed, and replayed with modified authentication contexts

In WebApp DAST scenarios, the primary user is utilized for exploration and crawling to discover API endpoints through browser interactions. Secondary users are then employed to replay the captured API traffic with different authentication credentials, validating that the underlying APIs properly enforce authorization boundaries.

The Nature of Tenant Isolation Vulnerabilities¶

Tenant isolation vulnerabilities manifest when authentication and authorization mechanisms fail to prevent unauthorized cross-tenant or cross-user data access. These vulnerabilities typically exhibit one or more of the following characteristics:

Authorization Bypass Through Direct Object Reference:

Resource identifiers (IDs, UUIDs, keys) are accepted by API endpoints without validating that the authenticated user has authorization to access the referenced resource. This allows an attacker to enumerate or guess identifiers belonging to other users or tenants and retrieve their data.

Data Leakage Through Insufficient Response Filtering:

API responses contain data belonging to multiple users or tenants without proper filtering based on the requesting user's authorization context. This occurs when queries or data aggregation operations fail to apply tenant-scoping predicates.

How Escape Validates Authorization Boundaries¶

Once multiple users are configured in the scan's authentication settings, Escape automatically orchestrates authorization testing through credential replay and response analysis:

Credential Replay Testing:

API requests discovered or generated during exploration are systematically replayed with the authentication credentials of different users. Responses are compared to detect authorization failures.

Response Analysis and Fingerprinting:

Escape employs sophisticated response fingerprinting algorithms to detect when different users receive substantively identical responses, indicating potential authorization bypass. The analysis accounts for expected variations (timestamps, session identifiers, user-specific metadata) while identifying semantically equivalent data access.

Tenant Isolation Security Testing¶

In multi-tenant architectures where multiple customers share a common software instance, tenant isolation represents a critical security boundary. When two or more users are configured in a scan profile, Escape's authorization testing engine automatically validates tenant isolation by systematically comparing API responses across different authenticated contexts.

Automated Testing Methodology:

Escape's business logic analysis algorithms perform cross-user request replay while applying response similarity detection and endpoint sensitivity classification. This automated approach identifies authorization breaches without requiring manual test case definition for each endpoint.

GraphQL-Specific Challenges:

GraphQL APIs present unique tenant isolation challenges due to their flexible query structures and type systems. Consider a GraphQL schema that exposes a User type with an email field. Without proper field-level authorization, queries that legitimately return user objects may inadvertently leak email addresses across tenant boundaries—a privacy violation that could constitute a compliance breach under GDPR, CCPA, or HIPAA regulations.

The GraphQL type system's interconnected nature means that authorization failures in one type can cascade through relationship traversals, enabling deep information disclosure through multi-hop queries. Escape's Tenant Isolation testing validates that distinct users cannot access identical GraphQL objects or retrieve the same scalar field values when such access would violate tenant boundaries.

Configuration Approaches¶

Escape provides three configuration strategies for tenant isolation testing, each suited to different levels of specificity and customization requirements. All configurations are supported in both API DAST and WebApp DAST modes.

Approach 1: Natural Language Rule Generation (AI-Assisted)¶

Escape's AI-powered configuration system enables tenant isolation rules to be defined through natural language descriptions. An LLM analyzes the provided description and generates appropriate detection logic tailored to the specified use case.

Configuration Example:

security_tests:
  tenant_isolation:
    main_user: 'user1' # Primary user for exploration and baseline establishment
    natural_language_rule: |
      Ensure that a user's notes cannot be accessed by other users.

How This Works:

The natural language description is processed by Escape's agentic system, which generates a set of detection rules that validate the specified authorization boundary. The generated rules can be reviewed in the scan logs by searching for [Agentic - Tenant Isolation].

Rule Generation Visibility:

The AI-generated detection logic is transparently displayed during scan execution:

Issue Reporting:

When a tenant isolation violation is detected, the specific rule that triggered the finding is displayed alongside the vulnerability details:

When to Use This Approach:

This method is recommended when authorization boundaries can be clearly articulated in business logic terms, and when rapid configuration without deep technical rule definition is desired. It is particularly effective for domain-specific isolation requirements that would be cumbersome to express in low-level detection predicates.

Approach 2: Default Fingerprint-Based Detection¶

Escape's default tenant isolation configuration employs response fingerprinting to automatically detect authorization failures across the majority of API architectures without requiring custom rule definition.

Configuration Example:

security_tests:
  tenant_isolation:
    main_user: 'user1' # Primary user for exploration and baseline establishment
    other_users:
      detect: # Conditions that indicate broken tenant isolation
      # Triggers when authenticated requests return identical response fingerprints across users
      - if_: request.is_authenticated
        is_: true
      - if_: helpers.fingerprints.same
        is_: true

Detection Logic:

This configuration validates that when the same API request is issued by different authenticated users, the response fingerprints differ. A match indicates that both users received substantively identical data, suggesting the API failed to apply proper authorization filtering.

Validation Criteria:

1. Both requests are authenticated (not anonymous access scenarios)
2. The same API endpoint is targeted with equivalent parameters
3. Only the authentication credentials differ between requests
4. Response fingerprints are analyzed for semantic equivalence

Fingerprint Analysis:

Escape's fingerprinting algorithm normalizes responses by excluding expected per-user variations (session tokens, timestamps, request IDs) while preserving semantic content structure. This approach provides robust detection across diverse API response formats (JSON, XML, GraphQL) without requiring schema-specific configuration.

When to Use This Approach:

This default configuration is recommended for initial tenant isolation validation and provides effective coverage for standard multi-tenant architectures. It requires minimal configuration while delivering high-confidence detection for most authorization bypass scenarios.

Approach 3: Custom Detection Rules (Precision Targeting)¶

For complex scenarios where responses contain expected per-user variations (timestamps, user-specific metadata, localization data) but specific data elements must remain tenant-isolated, custom detection rules enable precision targeting of authorization boundaries.

Configuration Example:

security_tests:
  tenant_isolation:
    main_user: user1
    other_users:
      detect:
        # JSON path-based detection: Validates specific fields remain distinct across users
        - if: helpers.json_matches.all
          jq: '.notes[].content'  # Extract note content from all notes in response
          is: true  # Trigger if extracted values are identical across users
        # Regex-based detection: Identifies presence of user-specific data in other users' responses
        - if: helpers.regex_matches.all
          regex: '.*User 1 Private Note.*'  # Pattern matching sensitive data
          is: true  # Trigger if pattern found in both users' responses

Use Case for Custom Rules:

Custom detection rules are essential when:

• Partial Response Variation: API responses include dynamic per-user elements (timestamps, request IDs, session data) that cause fingerprint mismatches, while authorization-sensitive data remains identical
• Nested Data Structures: Authorization failures occur in specific nested fields or array elements within larger response objects
• Pattern-Based Detection: Specific data values, identifiers, or text patterns must be validated for cross-user isolation
• Compliance Requirements: Regulatory mandates require validation of specific PII or PHI field isolation

Detector Extensibility:

The detect block supports the complete range of detectors documented in Custom Rules - Detectors, including:

• JSON path extraction with JQ queries
• Regular expression pattern matching
• Response code analysis
• Header inspection
• Composite boolean logic (AND, OR, NOT operations)

This extensibility enables arbitrarily complex authorization validation logic to be expressed declaratively.

Additional Resources:

For comprehensive information on tenant isolation vulnerability classification, remediation guidance, and real-world exploitation scenarios, consult the Tenant Isolation Vulnerability Documentation.