Configuration

Frontend DAST Configuration¶

Most of your scan configuration already follows the existing API DAST scan configuration, such as authentication.

However, there are a few additional configurations that are specific to SPA DAST scans.

Security Checks Configuration¶

You can control which types of security checks are performed during your frontend scan for optimal speed and coverage.

Granular Security Checks Control¶

The frontend_security_checks_enabled parameter allows you to precisely control which security checks to run:

scan:
  frontend_security_checks_enabled:
    - ALL  # Enable all security checks (default)

Available Security Check Types:

• ALL - Enable all security checks (default behavior)
• NONE - Disable all security checks (crawling only)
• ACTIVE_PAGE_CHECKS - Active page security testing (XSS, SQL injection, command injection, etc.)
• PASSIVE_PAGE_CHECKS - Passive page analysis (DOM security, browser storage, console errors, etc.)
• NETWORK_CHECKS - Network-level security analysis (headers, cookies, SSL, dependencies, etc.)
• API_CHECKS - API traffic security analysis (captured API calls from frontend)

Example Configurations:

# Fast scan: Only passive checks and network analysis
scan:
  frontend_security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS

# API-focused scan: Only analyze captured API traffic
scan:
  frontend_security_checks_enabled:
    - API_CHECKS

# Comprehensive security testing (same as ALL)
scan:
  frontend_security_checks_enabled:
    - ACTIVE_PAGE_CHECKS
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS
    - API_CHECKS

# Crawling only: No security checks
scan:
  frontend_security_checks_enabled:
    - NONE

Legacy Configuration (Deprecated)¶

For backward compatibility, the following legacy parameters are still supported but are simply presets of frontend_security_checks_enabled.

scan:
  # Legacy: Use frontend_security_checks_enabled instead
  frontend_crawling_only: true  # Equivalent to frontend_security_checks_enabled: [NONE]
  read_only: true              # Disables active security checks only

Authentication¶

Just like API scans, you can configure a simple header authentication preset for now.

presets:
  - type: headers
    users:
      - headers:
          Authorization: Bearer user1Token
        username: user1
validation: false

Blocklist configuration¶

Just like API scans, you can also configure blocklisted paths in your frontend scans. These support regex patterns. This enables you to optimize the scanner time by avoiding crawling useless pages, like /faq/ and articles.

blocklist:
  routes:
    - path: .*faq.*
    - path: .*help.*

Scope Configuration¶

In your Expert Configuration section in the settings of your scan, you can configure the domains in scope of your scan. This allows the frontend scanner to capture underlying traffic to subdomains, enabling generation of OpenAPI schemas of all your APIs used by the frontend, but also security analysis of the traffic. Domain scopes are filled by your organization's domains by default. Set it to "self" to allow only the current frontend domain.

scan:
  frontend_in_scope_domains:
    - 'example.com'
    - 'example.dev'
    - 'example.io'
authentication: {}

Hotstart Base URLs¶

In your Expert Configuration section in the settings of your scan, you can configure and add more base URLs for your scan. Base URLs is a list of URLs that the scanner should visit. You can pre-seed the scanner with a list of URLs to start the scan from and enrich the crawling process by boosting known URLs.

scan:
  hotstart:
    - https://example.com/user
    - https://example.com/user/profile
authentication: {}

Maximum scan duration¶

You can configure your scan time in minutes, to achieve better coverage for bigger web applications.

Maximum is 8 hours = 480 minutes Default for Frontend scans: 120 minutes

scan:
  max_duration: 120

Single page worker mode¶

For specific use-cases where your web application can only be used in a single page, without any reloads or navigations or page refresh (F5 etc...), this mode will force the scanner to only run in a single page and purely navigate in the elements of that page, not through any other URLs.

scan:
  frontend_single_page_worker: true

Worker Parallelism¶

To speed up or slow down your scan, you can configure the number of simultaneous opened pages for the scanner. Maximum allowed is 5 due to memory constraints. If you observe stability issues with failed scans, you can try to lower this value. Default is 3.

scan:
  frontend_parallel_workers: 3

Integrated authentication¶

For specific use cases where the browser-based authentication MUST happen in the same browser as the scanner engine, this option enables you to play the authentication procedure inside the scanner directly. This can help with specific authentication mechanism that rely on in-memory values, web-workers etc...

In most cases, automatic extraction of cookies, local storage, session storage in the default browser-based login will be sufficient and inject the values into the engine.

scan:
  frontend_integrated_authentication: true

Scan Persistence¶

To speed up the scan, you can enable persistence mode. This will save URLs from previous scans and load them into the scanner engine. This is enabled by default to enhance crawling stability.

scan:
  frontend_use_persistence: true

X-Escape-User header¶

Disabled by default to avoid breaking web applications. If enabled, attaches the currently logged-in user name from your authentication configuration, into a X-Escape-User header in all requests.

scan:
  frontend_escape_user_header: true

Blocked Element Selectors¶

You can configure a list of element selectors that the scanner should not interact with during the frontend scan. This is useful for avoiding interactions with elements that could disrupt the scan or the application state, such as logout buttons, help widgets, chat boxes, etc.

scan:
  frontend_blocklisted_element_selectors:
    - "#logout-button"
    - ".help-widget"
    - "#chat-box"
    - ".lock-account-button"

Sitemap Prefetching¶

By default, the scanner will attempt to prefetch and use any available sitemaps (robots.txt, sitemap.xml, etc.) as seeds for the crawler. This helps improve coverage by starting with a known set of URLs. You can disable this feature if needed:

scan:
  frontend_prefetch_sitemap: false

Fragment and Query Parameter Limits¶

You can control how many times the scanner visits pages with the same fragments or query parameters to optimize the crawling process:

scan:
  frontend_max_fragments_visits: 3      # Maximum visits to a page with same fragment
  frontend_max_query_params_visits: 3   # Maximum visits to a page with same query parameters
  frontend_max_parameter_occurence: 5   # Maximum occurrences of a parameter in a URL

User Agent Configuration¶

You can specify a custom user agent string for the frontend scanner:

scan:
  frontend_user_agent: "My Custom User Agent String"