Tuning Guide
Frontend DAST Tuning Guide¶
Frontend scans are highly dependent on your web application's architecture, routing complexity, and performance characteristics. Understanding how to tune your scan parameters can significantly improve scan effectiveness while avoiding common pitfalls.
Understanding Web Application Routing Patterns¶
The way your web application handles routing significantly impacts how the scanner discovers and navigates content. Understanding your routing pattern helps optimize scan parameters:
Path-Based Routing (Traditional Multi-Page)¶
Applications with distinct URLs for each page:
https://example.com/login
https://example.com/dashboard
https://example.com/users/profile
https://example.com/settings/account
The scanner engine will also automatically detect parameterized paths, and avoid visiting too many similar pages, for example:
https://example.com/users/5c773acd-fda4-481c-b82c-a608f8848161/profile
https://example.com/users/2fe704f9-c6ea-4675-a62c-286885be5bb0/profile
https://example.com/users/927eb8e1-473b-4918-baaa-8f7b02562d77/profile
Will always be detected as the same page and avoid over-crawling to reduce scan time.
Optimization: These benefit from sitemap prefetching and can handle moderate parallelism well since each URL represents a distinct page.
Fragment-Based Routing (Hash Routing)¶
Single-page applications using URL fragments for navigation:
https://example.com/#/login
https://example.com/#/dashboard
https://example.com/#/users/profile
https://example.com/#/settings/account
Optimization: Configure frontend_max_fragments_visits
to limit repetitive crawling of the same base URL with different fragments.
Query Parameter-Based Routing¶
Applications that use query parameters to determine content:
https://example.com/?page=login
https://example.com/?section=dashboard&tab=overview
https://example.com/?view=users&action=profile&id=123
Optimization: Set frontend_max_query_params_visits
and frontend_max_parameter_occurence
to prevent endless parameter exploration.
Single-URL Single Page Applications¶
Applications that dynamically load all content without changing the URL:
Optimization: Enable frontend_single_page_worker: true
to prevent unnecessary navigation attempts and focus on element interaction within the page.
Performance vs. Completeness Trade-offs¶
Scan Duration and Parallelism¶
Longer scans with more workers can find more content, but higher parallelism may overwhelm some applications and cause instability. The engine being based on a real browser engine, the parallelism will consume more memory if your application is heavy (interactivity, videos, animations).
scan:
max_duration: 240 # 4 hours for comprehensive coverage
frontend_parallel_workers: 3 # Balanced approach - start here
For production systems or applications that show signs of stress:
Parallelism Considerations
Higher parallelism (4-5 workers) can stress your application, potentially causing timeouts, memory issues, or service degradation. Always start with the default (3 workers) and only increase if your application handles the load well during testing.
Crawling Depth vs. Efficiency¶
Control how thoroughly the scanner explores similar pages:
scan:
# Reduce repetitive crawling for efficiency
frontend_max_fragments_visits: 2
frontend_max_query_params_visits: 2
frontend_max_parameter_occurence: 3
Stability Optimization¶
Some applications may experience issues under scanning load. If you encounter scan failures, timeouts, or application instability:
- Reduce parallelism - Lower
frontend_parallel_workers
to 1 or 2 - Enable persistence - Ensure
frontend_use_persistence: true
for better reliability - Use integrated authentication - Set
frontend_integrated_authentication: true
for complex auth flows - Block problematic elements - Add selectors to
frontend_blocklisted_element_selectors
Testing Approach
Start with conservative settings in a staging environment to determine your application's optimal configuration before running production scans.
scan:
frontend_parallel_workers: 1
frontend_use_persistence: true
frontend_integrated_authentication: true
frontend_blocklisted_element_selectors:
- "#chat-widget"
- ".modal-overlay"
- "[data-action='logout']"
Preventing De-authentication During Scans¶
One of the most common issues during frontend scans is unintentional logout, which can significantly impact scan coverage and effectiveness. De-authentication can happen through two main channels:
Frontend Element Interactions¶
Although we have built-in forbidden element lists, the scanner may sometimes interact with logout buttons, account deletion links, or session-ending elements that aren't automatically detected. You can prevent this by adding specific element selectors to the blocklist using Playwright locator syntax:
scan:
frontend_blocklisted_element_selectors:
# Standard logout elements
- "[data-testid='logout-button']"
- "button:has-text('Sign Out')"
- "a:has-text('Logout')"
- ".logout, .sign-out"
# Account management actions
- "[data-action='delete-account']"
- "button:has-text('Delete Account')"
- "[data-testid='deactivate-account']"
# Session management
- "button:has-text('End Session')"
- "[data-action='clear-session']"
# Navigation that might trigger logout
- "a[href*='/logout']"
- "a[href*='/sign-out']"
API Traffic Injection¶
During frontend scans, the scanner captures and analyzes API traffic from your application. The security testing engine may then inject payloads into these API requests, including authentication-related endpoints. This can inadvertently trigger logout or session invalidation without any visible indication in the frontend crawling process.
Common scenarios:
- Authentication token refresh endpoints receiving malformed requests
- Session management APIs being tested with invalid parameters
- User profile endpoints being tested with unauthorized payloads
- Multi-factor authentication APIs receiving unexpected data
Mitigation strategies:
## Option 1: Disable API traffic security testing
scan:
frontend_security_checks_enabled:
- ACTIVE_PAGE_CHECKS
- PASSIVE_PAGE_CHECKS
- NETWORK_CHECKS
# API_CHECKS excluded to avoid API injection
## Option 2: Use integrated authentication for session resilience
scan:
frontend_integrated_authentication: true
## Option 3: Avoid your authentication-related API domains with frontend_in_scope_domains
## For example, you have an auth-api.example.com that should not be scanned.
scan:
frontend_in_scope_domains:
- 'self' # for the current domain of the frontend
- 'api.example.com' # for the underlying API
Advanced Element Blocking¶
For complex applications, you may need more sophisticated element selectors:
scan:
frontend_blocklisted_element_selectors:
# Block by proximity to text
- "button:near(:text('Are you sure you want to log out?'))"
# Block modal actions
- ".modal button:has-text('Confirm')"
- "[role='dialog'] [data-action='confirm']"
# Block by CSS class patterns
- "[class*='danger']:has-text('Delete')"
- "[class*='destructive']:has-text('Remove')"
# Block by aria labels
- "[aria-label*='sign out']"
- "[aria-label*='log out']"
- "[aria-label*='delete account']"
Testing Element Selectors
Always test your element selectors in a development environment first. Overly broad selectors might block legitimate functionality, while too narrow selectors might miss logout elements with different styling or text.
Security vs. Performance Balance¶
Frontend DAST scans offer granular control over which security checks to perform, allowing you to optimize for speed or comprehensive coverage based on your needs.
Comprehensive Security Testing (Default)¶
Performance-Optimized Configurations¶
Fast Discovery Mode - Only crawl and analyze captured API traffic:
Passive Analysis Only - Skip resource-intensive active testing:
scan:
frontend_security_checks_enabled:
- PASSIVE_PAGE_CHECKS # DOM analysis, browser storage, console errors
- NETWORK_CHECKS # Headers, cookies, SSL analysis
- API_CHECKS # Captured API traffic analysis
Active Testing Focus - Prioritize active vulnerability detection:
scan:
frontend_security_checks_enabled:
- ACTIVE_PAGE_CHECKS # XSS, SQL injection, command injection
- API_CHECKS # API security testing
Crawling Only - Maximum speed, no security testing:
Legacy Configuration (Deprecated)¶
The following configurations are still supported but deprecated:
scan:
# DEPRECATED: Use frontend_security_checks_enabled instead
frontend_crawling_only: true # Equivalent to: [NONE]
read_only: true # Disables active checks only
Performance Recommendations
Development/Testing: Use ALL
for comprehensive security coverage CI/CD Pipeline: Use [PASSIVE_PAGE_CHECKS, API_CHECKS]
for faster feedback Discovery Phase: Use [API_CHECKS]
to map API surface quickly Production Validation: Use [NETWORK_CHECKS, API_CHECKS]
for minimal impact
Blocklist Strategy¶
Use blocklists to avoid wasting time on non-functional pages: