Skip to content

Automated Pentesting with our Multi-User BOLA Agent

The BOLA Testing Agent represents our first fully Agentic Automated Penetration Testing capability. By leveraging our existing DAST and API Testing infrastructure, this intelligent agent autonomously explores, analyzes, and exploits authorization vulnerabilities with unprecedented depth and accuracy. The agent automatically orchestrates multi-user attack scenarios, adapting its testing strategies based on application behavior to uncover complex authorization flaws that traditional scanners miss.

Multi-user security testing addresses two fundamental authorization security concerns: tenant isolation and privilege escalation. These use cases represent distinct security boundaries that must be validated in multi-user applications.

Multi-user Testing 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

Use Case 1: Tenant Isolation (Symmetric Permissions)

Tenant Isolation Overview

Tenant isolation testing validates 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.

Tenant Isolation Scenarios

Multi-Tenant SaaS Applications:

A CRM system must verify that Company A's administrators cannot access Company B's customer data, despite both having identical "Admin" permissions within their respective tenants.

Financial Services Platforms:

A banking application must ensure that premium account holders cannot access transaction histories or account details of other premium account holders in different organizations.

Educational Platforms:

An LMS must validate that instructors in Organization A cannot view course content, student submissions, or grades from Organization B, despite having equivalent "Instructor" privileges.

Tenant Isolation Implementation

A single scan profile is configured with one user designated as the primary exploration user, while additional users from different tenants are designated as exploitation targets. The scanner automatically tests for Broken Access Control (BAC), Tenant Isolation, and Cross-Tenant Data Breach vulnerabilities by attempting to replay the primary user's requests with secondary users' credentials.

Example Configuration:

users:
  - username: admin-tenant-a@example.com  # Primary user - full exploration
    main_user: true
  - username: admin-tenant-b@example.com  # Exploitation target
    main_user: false

Why Single-Direction Testing Suffices

When users possess equivalent permissions across different tenants, authorization violations are inherently bidirectional. If Tenant A can access Tenant B's data, the same vulnerability mechanism allows Tenant B to access Tenant A's data. Testing in one direction automatically validates the security boundary in both directions due to permission symmetry.

Use Case 2: Privilege Escalation (Asymmetric Permissions)

Privilege Escalation Overview

Privilege escalation testing validates 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.

Privilege Escalation Scenarios

Enterprise Applications with RBAC:

An enterprise system must verify that standard members cannot access administrative endpoints or perform privileged operations, while administrators cannot inadvertently access or modify member-specific private data.

Healthcare Systems:

A medical records system must confirm that nurses cannot access physician-only treatment planning features, while physicians cannot access administrative billing records, representing distinct privilege domains within the same healthcare organization.

E-Commerce Platforms:

A marketplace must ensure that vendor users cannot access platform administrative functions, while platform administrators cannot directly modify vendor inventory without proper authorization workflows.

Privilege Escalation Implementation

Single Scan Profile Approach (Recommended for most cases):

A single scan profile can be configured with the higher-privileged user as the primary exploration user and lower-privileged users as exploitation targets. This configuration detects unauthorized access by lower-privileged users to administrative resources.

Example Configuration:

users:
  - username: admin@company.com      # Primary user - full exploration
    main_user: true
  - username: member@company.com     # Exploitation target
    main_user: false

Bidirectional Testing Approach (For comprehensive validation):

When validating that administrative accounts cannot access user-specific private data, or when testing complex permission hierarchies, two separate scan profiles should be created:

  • Scan Profile A: Administrator as primary user, member as exploitation target
  • Scan Profile B: Member as primary user, administrator as exploitation target

This bidirectional approach ensures that authorization failures are detected regardless of attack direction.

Why Bidirectional Testing May Be Required

Asymmetric permissions can create asymmetric attack surfaces. Administrative users may have access to endpoints that inadvertently leak member data through overly permissive queries, while members may have access to different endpoints that could be exploited for privilege escalation. Bidirectional testing captures both vulnerability classes when comprehensive validation is required.

Implementation Decision Guide

Choose Tenant Isolation Testing

When the following conditions apply:

  • Users have equivalent roles across different tenants or organizations
  • Data segregation between tenants is the primary security concern
  • Users should never access data from other tenants regardless of permission level
  • Example: Admin in Tenant A vs Admin in Tenant B

Choose Privilege Escalation Testing

When the following conditions apply:

  • Users have different roles within the same tenant or organization
  • Authorization hierarchy enforcement is the primary security concern
  • Lower-privileged users should not access higher-privileged functionality
  • Example: Member vs Admin within the same organization

Consider Bidirectional Testing

When the following conditions apply:

  • Complex permission hierarchies exist with multiple privilege domains
  • Higher-privileged users may inadvertently leak lower-privileged user data
  • Comprehensive authorization validation is required
  • Regulatory compliance mandates exhaustive testing