# 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: ```yaml 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. ```yaml frontend_dast: parallel_workers: 3 # Default - recommended starting point ``` **Comprehensive Coverage**: ```yaml frontend_dast: parallel_workers: 3 ``` **Stability-Focused Configuration**: ```yaml frontend_dast: parallel_workers: 1 ``` > [!WARNING] > > **Resource Considerations** > > Increasing parallelism adds application load and can cause timeouts or service degradation. Keep the default of 3 workers unless you've validated application stability under load. ### 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` ```yaml 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']" ``` > [!TIP] > > **Configuration Validation** > > Conservative settings should be tested in staging environments to determine optimal application configuration before production scans are executed. ## 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): ```yaml 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): ```yaml 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. ```yaml 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: ```yaml 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: ```yaml 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. ```yaml 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. > [!NOTE] > > **Global Rate Limiting** > > Rate limiting applies uniformly to all API endpoints discovered during WebApp scanning, regardless of domain or origin. Per-domain rate control isn't supported for WebApp DAST. ## 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**: ```yaml frontend_dast: security_checks_enabled: - API_CHECKS ``` Recommended for initial API surface mapping and CI/CD rapid feedback. **Passive and API Analysis Mode**: ```yaml frontend_dast: security_checks_enabled: - PASSIVE_PAGE_CHECKS - NETWORK_CHECKS - API_CHECKS ``` Recommended for production environments and continuous monitoring. **Active Testing Focus**: ```yaml frontend_dast: security_checks_enabled: - ACTIVE_PAGE_CHECKS - API_CHECKS ``` Recommended for pre-production security validation. **Crawling Only**: ```yaml frontend_dast: security_checks_enabled: - NONE ``` Recommended for application structure discovery and scope validation. **Comprehensive Testing**: ```yaml frontend_dast: security_checks_enabled: - ALL # Default ``` Recommended for development environments and comprehensive security assessments. > [!TIP] > > **Environment-Specific Recommendations** > > - Development/Testing: `ALL` for comprehensive coverage > - CI/CD Pipeline: `[PASSIVE_PAGE_CHECKS, API_CHECKS]` for faster feedback > - Discovery Phase: `[API_CHECKS]` for rapid API surface mapping > - Production: `[NETWORK_CHECKS, API_CHECKS]` for minimal impact ## 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: ```yaml 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]()