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:

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.

network:
  ff_frontend_next_sender: true

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

network:
  ff_frontend_next_sender: true

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.

network:
  ff_frontend_next_sender: true

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.

network:
  ff_frontend_next_sender: true

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.

network:
  ff_frontend_next_sender: true

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.