WebApp Multi-User Testing¶

The following configuration examples demonstrate common multi-user testing scenarios for WebApp Testing. These patterns can be adapted for API Testing by replacing the authentication.presets.type value with appropriate API authentication methods.

Pattern 1: Privilege Escalation (Asymmetric Permissions)¶

Scenario: Validation that a lower-privilege user cannot access features or data restricted to higher-privilege users within the same tenant.

Use Case: This pattern tests vertical authorization boundaries where users with different roles (e.g., admin vs member) within the same organization should have different access levels.

Configuration:

In order to configure this, you can use a natural language description as the following:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: admin@company.com
          password: SecurePassword123!
          main_user: true
        - username: standard_user@company.com
          password: StandardPassword456!
      login_url: https://app.company.com/login

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: admin@company.com
    natural_language_rule: |
      Ensure that standard users cannot access administrative features
      including user management, billing configuration, and system settings.
      Standard users should not be able to view or modify admin-only resources.

The above will use the given natural_language_rule to generate a reusable list of Detectors. In order to view the generated detection rules, you can search for [Agentic - Tenant Isolation] in scan logs tab. You can also directly write your own list of conditions for validating cross-tenant isolation as the following:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: admin@company.com
          password: SecurePassword123!
          main_user: true
        - username: standard_user@company.com
          password: StandardPassword456!
      login_url: https://app.company.com/login

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: admin@company.com
    other_users:
      detect:
        - if: schema.path_ref
          regex: /api/admin/.*

The above will make sure that all of the other users cannot access the routes matching regex /api/admin/.*.

Testing Behavior:

• The application is crawled using the admin@company.com authentication context
• All administrative features accessible to the admin user are discovered
• Authorization tests are performed by replaying admin-accessible requests with standard_user@company.com credentials
• Violations are detected when the standard user successfully accesses admin-restricted features

When to Use This Pattern:

This configuration is appropriate for Privilege Escalation testing when validating role-based access control (RBAC) within a single tenant or organization, where different user roles (admin, member, viewer) should have different permission levels.

Pattern 2: Tenant Isolation (Symmetric Permissions)¶

Scenario: Validation that users in different tenants cannot access each other's data, despite having equivalent permission levels.

Use Case: This pattern tests horizontal authorization boundaries where users with the same role (e.g., admin in Tenant A vs admin in Tenant B) should remain strictly isolated from each other's data.

Configuration:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: user@tenant-a.com
          password: TenantAPassword123!
          main_user: true
      login_url: https://app.company.com/tenant-a
    - type: browser_agent
      users:
        - username: user@tenant-b.com
          password: TenantBPassword456!
      login_url: https://app.company.com/tenant-b

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: user@tenant-a.com

Testing Behavior:

• The application is crawled using the user@tenant-a.com authentication context
• All features accessible to Tenant A's user are discovered
• Authorization tests are performed by replaying Tenant A's requests with user@tenant-b.com credentials
• Violations are detected when the Tenant B user successfully accesses Tenant A's data

When to Use This Pattern:

This configuration is appropriate for Tenant Isolation testing in multi-tenant SaaS applications where data segregation between tenants is a critical security requirement. This pattern validates that users with equivalent roles (e.g., both admins) in different tenants cannot access each other's data. Note that separate authentication presets are used when tenants have different login URLs or authentication flows.

Pattern 3: Multiple Secondary Users (Consolidated Testing)¶

Scenario: Validation that multiple users (different roles, different tenants, or both) cannot access the Main User's data.

Use Case: This pattern can test both Privilege Escalation and Tenant Isolation simultaneously by including users from different privilege levels within the same tenant and users from different tenants.

Configuration:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: privileged_user@tenant-a.com
          password: PrivilegedPassword123!
          main_user: true
        - username: standard_user@tenant-a.com
          password: StandardPassword456!
      login_url: https://app.company.com/tenant-a
    - type: browser_agent
      users:
        - username: user@tenant-b.com
          password: TenantBPassword789!
      login_url: https://app.company.com/tenant-b

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: privileged_user@tenant-a.com
    natural_language_rule: |
      Ensure that users from other tenants cannot access Tenant A's data.
      Additionally, ensure that standard users within Tenant A cannot access
      privileged user features such as organization settings and billing.

However, if you want to be more precise of which detection rules must be applied per user (i.e. different roles that may share certain actions), you can specify a list of rules for each user as the following:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: privileged_user@example.com
          password: PrivilegedPassword123!
          main_user: true
        - username: publisher@example.com
          password: PublisherPassword456!
        - username: seller@example.com
          password: SellerPassword789!
        - username: low_priv@example.com
          password: LowPrivPassword789!
      login_url: https://app.company.com/login

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: privileged_user@example.com
    other_users:
      detect:
        - if: schema.path_ref
          regex: /api/admin/.*
    specific_users:
      seller@example.com:
        detect:
          - if: schema.path_ref
            regex: /api/admin/.*
          - if: schema.path_ref
            is_not: /api/admin/transactions

The example above will not allow all the users to access endpoints matching /api/admin/.* and allow seller@example.com to only access /api/admin/transactions.

Testing Behavior:

• The application is crawled using the privileged_user@tenant-a.com authentication context
• Authorization tests are performed for both secondary users:
  • standard_user@tenant-a.com attempts to access privileged user's data (Privilege Escalation testing - same tenant, different roles)
  • user@tenant-b.com attempts to access privileged user's data (Tenant Isolation testing - different tenants)
• Violations are detected when either secondary user successfully accesses the Main User's data

Important Limitations:

• standard_user@tenant-a.com access to user@tenant-b.com data is NOT tested
• If user@tenant-b.com has access to features not accessible to the Main User, those features will NOT be tested

When to Use This Pattern:

This configuration is efficient when both Privilege Escalation and Tenant Isolation must be validated simultaneously against a single privileged account. It is particularly useful when the privileged user has the broadest feature access, ensuring maximum application coverage while testing multiple authorization boundaries in a single scan.

Pattern 4: Bidirectional Privilege Escalation Testing¶

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

Use Case: This pattern provides comprehensive Privilege Escalation testing when administrative users may inadvertently access lower-privileged user private data, in addition to preventing lower-privileged users from accessing administrative functions.

Implementation: Two separate scan profiles must be configured.

Scan Profile A Configuration:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: admin@company.com
          password: AdminPassword123!
          main_user: true
        - username: manager@company.com
          password: ManagerPassword456!
      login_url: https://app.company.com/login

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: admin@company.com
    natural_language_rule: |
      Ensure that managers cannot access administrative features such as
      user role assignment, security settings, and audit logs.

Scan Profile B Configuration:

authentication:
  presets:
    - type: browser_agent
      users:
        - username: manager@company.com
          password: ManagerPassword456!
          main_user: true
        - username: admin@company.com
          password: AdminPassword123!
      login_url: https://app.company.com/login

frontend_dast:
  max_duration: 180
  static_crawling:
    enabled: true
    time_limit_seconds: 300
  agentic_crawling:
    enabled: true

security_tests:
  tenant_isolation:
    skip: false
    main_user: manager@company.com
    natural_language_rule: |
      Ensure that administrators cannot access manager-specific private data
      such as personal performance reviews, team communications, or draft documents.

Testing Behavior:

• Scan Profile A: Tests whether managers can access admin-restricted features
• Scan Profile B: Tests whether admins can access manager-private data

Why Both Scans Are Required:

In Privilege Escalation scenarios with asymmetric permissions, attack surfaces can be bidirectional. The admin may have access to endpoints that inadvertently leak manager-private data, while the manager may have access to different endpoints that could be exploited for privilege escalation. Only bidirectional testing detects both vulnerability classes when comprehensive validation is required.