Skip to content

Multi-User BOLA Testing

Business Logic Aware DAST multi-user testing performs technical authorization tests by replaying authenticated requests across different user contexts and enumerating object IDs to detect Broken Object-Level Authorization (BOLA), tenant isolation violations, and privilege escalation vulnerabilities.

How It Works

Business Logic Aware DAST performs two types of technical tests:

  • ID Enumeration: Tests for unauthorized access by enumerating object IDs (e.g., user IDs, resource IDs) discovered during scanning
  • Request Replay: Replays requests discovered with the main user's credentials using other configured users' credentials to detect authorization failures

Use Cases

Tenant Isolation (Symmetric Permissions)

Tests data segregation between accounts or organizations with equivalent permission levels. This scenario tests horizontal authorization boundaries where users possess identical roles but should remain strictly isolated from each other's data.

Example: Multi-tenant SaaS applications where users from different tenants should not access each other's data, even when they have equivalent roles (e.g., Admin in Tenant A vs Admin in Tenant B).

Privilege Escalation (Asymmetric Permissions)

Tests authorization controls between users with different privilege levels within the same tenant or organizational context. This scenario tests vertical authorization boundaries where users with lower privileges should not access resources or perform actions reserved for higher-privileged users.

Example: Applications with role-based access control where users with different privilege levels within the same tenant should have different access (e.g., Member vs Admin within the same organization).

Requirements

An API endpoint or GraphQL operation will be tested in multi-user scenarios only if it meets all of the following conditions:

  • Non-empty response for read operations: If the request is reading data (GET request or GraphQL query), the response must not be empty
  • Successful exchange: The request must have resulted in a successful HTTP exchange
  • At least one argument: The request must have at least one argument (query parameter, path parameter, or body argument)
  • Multiple users configured: More than one user must be configured in the scan
  • Authentication success: Authentication must not have failed for the other users

Configuration

Main User Concept

Multi-user security testing follows a unidirectional testing model centered on the Main User concept:

  1. Exploration Authority: The Main User's authentication context is used for application crawling and endpoint discovery. Only features, pages, and API endpoints accessible to the Main User will be included in the security assessment.
  2. Victim Perspective: The Main User is treated as the victim in access control testing scenarios. Other configured users attempt to access data and resources belonging to the Main User.

Testing Direction: Access control testing is performed exclusively in one direction: from Other Users toward the Main User.

Configuration Approaches

Approach 1: Natural Language Rules

Define authorization policies in plain language. An LLM analyzes the description and generates detection logic.

Tenant Isolation Example:

authentication:
  presets:
    - type: bearer_token
      users:
        - username: user@tenant-a.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
          main_user: true
        - username: user@tenant-b.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

security_tests:
  tenant_isolation:
    main_user: user@tenant-a.com
    natural_language_rule: |
      Ensure that a user's notes cannot be accessed by other users.

Privilege Escalation Example:

authentication:
  presets:
    - type: bearer_token
      users:
        - username: admin@company.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
          main_user: true
        - username: member@company.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

security_tests:
  tenant_isolation:
    main_user: admin@company.com
    natural_language_rule: |
      Ensure that standard members cannot access administrative endpoints or perform privileged operations:
      - Members cannot access user management endpoints
      - Members cannot modify system configuration
      - Members cannot view audit logs

Approach 2: Default Fingerprint-Based Detection

Default configuration uses response fingerprinting to automatically detect authorization failures without manual configuration.

authentication:
  presets:
    - type: bearer_token
      users:
        - username: user1@example.com
          token: token1
          main_user: true
        - username: user2@example.com
          token: token2

security_tests:
  tenant_isolation:
    main_user: user1@example.com
    other_users:
      detect:
        - if_: request.is_authenticated
          is_: true
        - if_: helpers.fingerprints.same
          is_: true

Approach 3: Custom Detection Rules

For precision targeting, define custom detection rules using detectors.

security_tests:
  tenant_isolation:
    main_user: user1
    other_users:
      detect:
        - if: helpers.json_matches.all
          jq: '.notes[].content'
          is: true
        - if: helpers.regex_matches.all
          regex: '.*User 1 Private Note.*'
          is: true

Examples

API Testing - Tenant Isolation

authentication:
  presets:
    - type: bearer_token
      users:
        - username: user@tenant-a.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
          main_user: true
        - username: user@tenant-b.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

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

API Testing - Privilege Escalation

authentication:
  presets:
    - type: bearer_token
      users:
        - username: admin@company.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
          main_user: true
        - username: member@company.com
          token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

security_tests:
  tenant_isolation:
    skip: false
    main_user: admin@company.com
    natural_language_rule: |
      Ensure that standard members cannot access administrative features
      including user management, billing configuration, and system settings.

WebApp Testing - Privilege Escalation

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.

Note: For API Testing, remove the frontend_dast configuration block and use appropriate API authentication methods (http_basic, bearer_token, cookie, header, or manual).

Detection Capabilities

The scanner supports three approaches for defining authorization rules:

  • Natural Language Rules: Authorization policies defined in plain language and automatically translated into detection logic
  • Automatic BOLA Scanning: Fingerprint-based detection of unauthorized data access without manual configuration (default approach)
  • Custom Detection Rules: Precise targeting with technical detection rules for specific authorization boundaries