WebApp Testing Performance Tuning¶

Performance optimization in WebApp Testing requires balancing scan thoroughness against resource utilization, scan duration, and application stability. This guide provides systematic approaches to optimize scan performance based on application characteristics and testing objectives.

Complete Configuration Example¶

The following configuration provides a balanced performance setup suitable for most applications:

frontend_dast:
  # Parallelism and resource management
  parallel_workers: 3

  # Security check selection
  security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS
    - API_CHECKS

  # Crawling efficiency
  crawling_tuning:
    # Visit limits
    max_parameterized_url_variations: 5
    max_unique_fragments_per_page: 5
    max_unique_values_per_query_param: 5

  # Crawling blocklist strategy
  scope:
    crawling:
      blocklist:
        - type: web_page_url
          value: ".*/help/.*"
          operation: regex
        - type: web_page_url
          value: ".*/faq.*"
          operation: regex
        - type: web_page_url
          value: ".*/privacy.*"
          operation: regex
        - type: web_page_url
          value: ".*/terms.*"
          operation: regex
        - type: web_page_url
          value: ".*/blog/.*"
          operation: regex

# API rate limiting
network:
  requests_per_second: 50  # Schema default: 100; UI-created profiles: 500

This configuration disables active page checks while retaining passive, network and captured API checks.

Parallelism and Resource Management¶

Browser Parallelism¶

The number of concurrent pages in a shared browser context is controlled through parallel_workers (range 1 to 20, default 3). Higher parallelism accelerates coverage but increases memory consumption and application load.

frontend_dast:
  parallel_workers: 3  # Default - recommended starting point

Comprehensive Coverage:

frontend_dast:  
  parallel_workers: 3

Stability-Focused Configuration:

frontend_dast:
  parallel_workers: 1

Stability Optimization¶

When scan failures, timeouts, or application instability are encountered, the following adjustments should be applied sequentially:

1. Parallelism should be reduced to 1 or 2 workers
2. Configure a supported authentication preset, enable authentication.validation, and review logout detection for complex login flows
3. Problematic elements should be added to scope.crawling.blocklist using type: web_page_element_selector

frontend_dast:
  parallel_workers: 1
  scope:
    crawling:
      blocklist:
        - type: web_page_element_selector
          value: "#chat-widget"
        - type: web_page_element_selector
          value: ".modal-overlay"
        - type: web_page_element_selector
          value: "[data-action='logout']"

Scan Duration Configuration¶

Set Max duration on the profile: the UI range is 1 to 10 hours, with a default of 4 hours. The profile value overrides max_duration in the saved expert YAML configuration. A single-scan configuration override can replace that value. It directly impacts coverage depth. The following durations and YAML tunings are recommended based on testing objectives:

Quick Assessment (about 1 hour):

frontend_dast:
  parallel_workers: 1
  crawling_tuning:
    max_parameterized_url_variations: 3
    max_unique_fragments_per_page: 3
    max_unique_values_per_query_param: 3

Standard Testing (60-240 minutes):

frontend_dast:
  parallel_workers: 3

Extended Coverage (3-10 hours):

Set Max duration on the profile to 3-10 hours when comprehensive coverage is required. Known entry points should also be added to the hotstart list. Sitemaps are prefetched automatically during scan initialization when the application exposes them.

Crawling Entry Points and Static Seeding¶

frontend_dast.hotstart is a list of URLs to seed exploration. Static crawling also extracts seed URLs: static_crawling.enabled defaults to true, and time_limit_seconds defaults to 300. Static crawling is disabled in single page worker mode.

frontend_dast:
  hotstart:
    - https://app.example.com/account
  static_crawling:
    enabled: true
    time_limit_seconds: 300

frontend_dast.in_scope_only defaults to false. Setting it to true disables extensive endpoint fuzzing outside the supplied specification, including exposed .git and .env checks. It isn't a browser traffic blocklist.

Crawling Efficiency¶

Visit Limits¶

Exhaustive exploration of parameterized content can be prevented through visit limits, significantly reducing scan duration:

frontend_dast:
  crawling_tuning:
    max_parameterized_url_variations: 5
    max_unique_fragments_per_page: 5
    max_unique_values_per_query_param: 5

These settings prevent the scanner from exhaustively testing every parameter combination, which is particularly important for applications with dynamic URLs.

• max_parameterized_url_variations: Limits exploration of URL paths and fragments that vary by identifiers, including numbers and UUIDs, for example /users/{id}/profile
• max_unique_values_per_query_param: Limits values tested per query parameter
• max_unique_fragments_per_page: Limits URL fragment variations per base path

Blocklist Strategy¶

Time can be conserved by excluding non-functional pages through blocklists:

frontend_dast:
  scope:
    crawling:
      blocklist:
        - type: web_page_url
          value: ".*/help/.*"
          operation: regex
        - type: web_page_url
          value: ".*/faq.*"
          operation: regex
        - type: web_page_url
          value: ".*/privacy.*"
          operation: regex
        - type: web_page_url
          value: ".*/terms.*"
          operation: regex
        - type: web_page_url
          value: ".*/blog/.*"
          operation: regex
        - type: web_page_url
          value: ".*/news/.*"
          operation: regex

API Rate Limiting¶

WebApp DAST captures and tests API traffic discovered during browser navigation. Rate limiting controls API security-check traffic. network.requests_per_second and network.request_timeout_s don't constrain browser navigation, form submissions or active page checks. Reduce parallel_workers and select fewer check families to reduce browser load.

network:
  requests_per_second: 50  # Schema default: 100; UI-created profiles: 500

The schema default is 100 requests per second (range 1 to 1000); UI-created profiles start at 500. When applications implement strict rate limiting, the requests_per_second parameter should be reduced incrementally. Default settings are recommended initially, with adjustments made only when rate limit errors are encountered during scanning.

Security Check Selection¶

Security check selection provides the most significant performance optimization opportunity. Different check types vary substantially in execution time and resource requirements.

Check Types¶

• ACTIVE_PAGE_CHECKS: Interactive injection testing (XSS, SQLi, command injection): highest resource consumption
• PASSIVE_PAGE_CHECKS: DOM analysis, browser storage inspection: minimal overhead
• NETWORK_CHECKS: Header analysis, cookie security, SSL configuration: low overhead
• API_CHECKS: Security testing of captured API traffic: moderate resource consumption

Performance-Oriented Configurations¶

Fast Discovery Mode:

frontend_dast:
  security_checks_enabled:
    - API_CHECKS

Recommended for initial API surface mapping and CI/CD rapid feedback.

Passive and API Analysis Mode:

frontend_dast:
  security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS
    - API_CHECKS

Recommended for production environments and continuous monitoring.

Active Testing Focus:

frontend_dast:
  security_checks_enabled:
    - ACTIVE_PAGE_CHECKS
    - API_CHECKS

Recommended for pre-production security validation.

Crawling Only:

frontend_dast:
  security_checks_enabled:
    - NONE

Recommended for application structure discovery and scope validation.

Comprehensive Testing:

frontend_dast:
  security_checks_enabled:
    - ALL  # Default

Recommended for development environments and comprehensive security assessments.

Common Performance Challenges¶

Scans Exceeding Time Constraints¶

When scans are timing out or taking too long, the following adjustments should be applied sequentially:

1. Increase parallel_workers cautiously, for example from 3 to 4, only after validating application stability under load
2. Problematic pages should be added to the blocklist
3. Security checks should be limited to essential types:

frontend_dast:
  parallel_workers: 4 # Increase only after validating stability
  security_checks_enabled:
    - API_CHECKS

Incomplete Application Coverage¶

When not all pages are discovered during scanning, coverage can be enhanced through:

• Increase Max duration within the 1-10 hour UI range
• Known URLs should be added to the hotstart list
• Visit limit parameters should be increased

Repetitive Page Exploration¶

When scans repeatedly visit similar pages with different parameters, parameter exploration should be constrained through the visit limits documented above. This behavior indicates that parameter exploration has not been properly constrained.

Related Documentation¶

• Session Management
• Production-Safe Scanning
• Configuration Reference