Skip to content

API DAST Configuration Patterns

The configuration patterns for API DAST are structurally similar to WebApp DAST examples, with the following modifications:

  1. Authentication Type: Replace browser_agent with appropriate API authentication methods (http_basic, bearer_token, cookie, header, or manual)
  2. Network Parameter: The network.ff_frontend_next_sender parameter is not required for API DAST scans
  3. Frontend DAST Block: Remove the frontend_dast configuration block

API DAST Example (Tenant Isolation Pattern)

Configuration:

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

This configuration validates tenant isolation for API endpoints by replaying requests with different bearer tokens and comparing response fingerprints.

Configuration Decision Tree

Should you use a single scan profile with multiple users, or multiple scan profiles?

Use a Single Scan Profile When:

  • All secondary users should be tested for their ability to access the Main User's data
  • The Main User has the broadest feature access (ensuring maximum coverage)
  • Testing direction is unidirectional (secondary users → Main User)

Use Multiple Scan Profiles When:

  • Bidirectional authorization testing is required (asymmetric permissions)
  • Different users have access to mutually exclusive features that must all be tested
  • Independent exploration of multiple user roles is necessary (Use Case 1)

Example Decision

Scenario: Testing a SaaS application with Admin, Manager, and Standard User roles

Question: Should this be one scan or three scans?

Answer: Depends on testing objectives:

  • Single Scan: If the goal is to validate that Manager and Standard User cannot access Admin data (one scan with Admin as Main User)
  • Multiple Scans: If the goal is to validate all three combinations (Admin→Manager, Manager→Admin, Standard→Manager requires three scans)
  • Use Case 1: If each role interacts with fundamentally different features requiring independent exploration (three separate scans)

Summary

Scenario Number of Scans Main User Selection Secondary Users
Symmetric tenant isolation (Use Case 2) 1 Any tenant user Other tenant users
Asymmetric permissions - unidirectional (Use Case 3, partial) 1 Higher privilege user Lower privilege users
Asymmetric permissions - bidirectional (Use Case 3, complete) 2 Reverse in each scan Opposite user
Independent user exploration (Use Case 1) N (number of roles) Each role separately None or for additional isolation testing
Multiple authorization boundaries against one user 1 Most privileged user All other users