Skip to content

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:

  1. Reduce parallelism - Lower frontend_parallel_workers to 1 or 2
  2. Enable persistence - Ensure frontend_use_persistence: true for better reliability
  3. Use integrated authentication - Set frontend_integrated_authentication: true for complex auth flows
  4. 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_send_api_traffic_to_checks: false

## Option 2: Use integrated authentication for session resilience
scan:
  frontend_integrated_authentication: true

## Option 3: Block authentication-related API routes
blocklist:
  routes:
    - path: ".*/auth/.*"
    - path: ".*/session/.*" 
    - path: ".*/token/.*"
    - path: ".*/logout.*"
    - path: ".*/refresh.*"

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

Full Security Testing

scan:
  frontend_crawling_only: false  # Enable all security checks
  frontend_send_api_traffic_to_checks: true  # Analyze captured API traffic

Fast Discovery Mode

scan:
  frontend_crawling_only: true  # Skip heavy security checks
  frontend_send_api_traffic_to_checks: true  # Still analyze API traffic

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