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
  max_duration: 120
  use_persistence: true

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

  # Crawling efficiency
  scope:
    pages:
      # Visit limits
      max_parameterized_url_variations: 5
      max_unique_fragments_per_page: 5
      max_unique_values_per_query_param: 5

      # Blocklist strategy
      blocklist_url_patterns:
        - ".*/help/.*"
        - ".*/faq.*"
        - ".*/privacy.*"
        - ".*/terms.*"
        - ".*/blog/.*"

This configuration achieves approximately 50% of full scan duration while maintaining comprehensive passive security analysis.

Parallelism and Resource Management¶

Browser Parallelism¶

The number of concurrent browser instances is controlled through the parallel_workers parameter. Higher parallelism accelerates coverage but increases memory consumption and application load.

frontend_dast:
  parallel_workers: 3  # Default - recommended starting point

Comprehensive Coverage:

frontend_dast:
  max_duration: 240
  parallel_workers: 3

Stability-Focused Configuration:

frontend_dast:
  max_duration: 60
  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. Persistence should be enabled via use_persistence: true
3. Integrated authentication should be enabled for complex authentication flows
4. Problematic elements should be added to blocklist_element_selectors

frontend_dast:
  parallel_workers: 1
  use_persistence: true
  integrated_authentication: true
  scope:
    pages:
      blocklist_element_selectors:
        - "#chat-widget"
        - ".modal-overlay"
        - "[data-action='logout']"

Scan Duration Configuration¶

Scan duration directly impacts coverage depth. The following configurations are recommended based on testing objectives:

Quick Assessment (30-60 minutes):

frontend_dast:
  max_duration: 60
  parallel_workers: 1
  scope:
    pages:
      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:
  max_duration: 240
  parallel_workers: 3

Extended Coverage:

The max_duration parameter can be increased to 180-240 minutes when comprehensive coverage is required. Additionally, the prefetch_sitemap setting should be enabled and known entry points should be added to the hotstart list.

Crawling Efficiency¶

Visit Limits¶

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

frontend_dast:
  scope:
    pages:
      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 testing of URLs with numeric or UUID segments (e.g., /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:
    pages:
      blocklist_url_patterns:
        - ".*/help/.*"
        - ".*/faq.*"
        - ".*/privacy.*"
        - ".*/terms.*"
        - ".*/blog/.*"
        - ".*/news/.*"

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 (~30% of full scan duration):

frontend_dast:
  security_checks_enabled:
    - API_CHECKS

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

Passive Analysis Mode (~50% of full scan duration):

frontend_dast:
  security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS
    - API_CHECKS

Recommended for production environments and continuous monitoring.

Active Testing Focus (~70% of full scan duration):

frontend_dast:
  security_checks_enabled:
    - ACTIVE_PAGE_CHECKS
    - API_CHECKS

Recommended for pre-production security validation.

Crawling Only (~10% of full scan duration):

frontend_dast:
  security_checks_enabled:
    - NONE

Recommended for application structure discovery and scope validation.

Comprehensive Testing (baseline - 100%):

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. The parallel_workers parameter should be reduced from 3 to 1
2. Persistence should be enabled via use_persistence: true
3. Problematic pages should be added to the blocklist
4. Security checks should be limited to essential types:

frontend_dast:
  parallel_workers: 1
  use_persistence: true
  security_checks_enabled:
    - API_CHECKS

Incomplete Application Coverage¶

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

• The max_duration parameter should be increased to 180-240 minutes
• Known URLs should be added to the hotstart list
• The prefetch_sitemap: true setting should be enabled
• 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