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:

https://example.com/ (all navigation happens within this single 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:

scan:
  max_duration: 60   # 1 hour for quick assessment
  frontend_parallel_workers: 1  # Safest option

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)¶

scan:
  frontend_security_checks_enabled:
    - ALL  # All security checks enabled

Performance-Optimized Configurations¶

Fast Discovery Mode - Only crawl and analyze captured API traffic:

scan:
  frontend_security_checks_enabled:
    - API_CHECKS  # Only 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:

scan:
  frontend_security_checks_enabled:
    - NONE  # Pure crawling for discovery

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:

blocklist:
  routes:
    - path: ".*/help/.*"      # Help documentation
    - path: ".*/faq.*"        # FAQ pages
    - path: ".*/privacy.*"    # Legal pages
    - path: ".*/terms.*"      # Terms of service
    - path: ".*/blog/.*"      # Blog articles
    - path: ".*/news/.*"      # News articles