WebApp DAST Configuration Patterns¶

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

Pattern 1: Asymmetric Permissions (High and Low Privilege Users in Same Tenant)¶

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

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 when testing role-based access control (RBAC) within a single tenant, where different user roles have different permission levels.

Pattern 2: Tenant Isolation (Users in Different Tenants)¶

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

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 multi-tenant SaaS applications where tenant data isolation is a critical security requirement. 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.

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 (intra-tenant privilege escalation testing)
- user@tenant-b.com attempts to access privileged user's data (cross-tenant isolation testing)
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 multiple authorization boundaries must be validated against a single privileged account. It is particularly useful when the privileged user has the broadest feature access, ensuring maximum application coverage.

Pattern 4: Bidirectional Asymmetric Testing¶

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

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:

Asymmetric permissions create asymmetric attack surfaces. The admin may have access to endpoints that inadvertently leak manager-private data, while the manager may have access to different endpoints that expose admin-restricted functionality. Only bidirectional testing detects both vulnerability classes.