Production-Safe Scanning¶

Use check selection, scope rules, and traffic controls to reduce the impact of production scans. Browser navigation and form submissions can still change application state, and scanning can trigger security alerts. Validate these settings in staging and coordinate with your operations team before scanning production.

Complete Configuration¶

The following configuration provides a comprehensive production-safe setup:

frontend_dast:
  # Security testing constraints
  security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS

  # Resource constraints
  parallel_workers: 1

  crawling_tuning:
    max_parameterized_url_variations: 2
    max_unique_fragments_per_page: 2

  # Scope controls
  scope:
    crawling:
      blocklist:
        - type: web_page_url
          value: ".*/admin/delete/.*"
          operation: regex
        - type: web_page_url
          value: ".*/payment/process/.*"
          operation: regex
        - type: web_page_element_selector
          value: 'button[data-action="delete"]'
        - type: web_page_element_selector
          value: 'button[type="submit"][class*="danger"]'
        - type: web_page_element_selector
          value: '[data-critical-action="true"]'

    api_testing:
      blocklist:
        - type: rest_api_path
          value: ".*/api/delete/.*"
          operation: regex
        - type: rest_api_path
          value: ".*/api/admin/.*"
          operation: regex

network:
  requests_per_second: 50
  request_timeout_s: 10
  custom_headers:
    user-agent:
      - "EscapeSecurity-ProductionScan/1.0 (Authorized-Scan)"
    X-Security-Scanner:
      - "Escape"
    X-Scan-Purpose:
      - "Production-Safety-Test"

Configuration Components¶

Security Check Selection¶

Security check types can be selectively enabled to balance thoroughness against production impact:

• ACTIVE_PAGE_CHECKS: Interactive vulnerability testing (XSS, SQL injection): highest impact
• PASSIVE_PAGE_CHECKS: Safe analysis (DOM security, browser storage, console errors): minimal impact
• NETWORK_CHECKS: Infrastructure analysis (headers, cookies, SSL): minimal impact
• API_CHECKS: Security testing of captured API traffic: moderate impact

Read-Only Mode:

For WebApps, mode: read_only disables ACTIVE_PAGE_CHECKS. With the default check selection, PASSIVE_PAGE_CHECKS, NETWORK_CHECKS and API_CHECKS still run. Captured API traffic is tested only for operations classified as reads.

mode: read_only

Browser navigation and form submissions can still create, update or delete data. To limit security testing to passive page and network analysis, explicitly select the check families below.

Explicit Check Selection:

frontend_dast:
  security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS

Rate Limiting and Traffic Control¶

Use network.requests_per_second to limit API-check traffic. The schema default is 100 requests per second; UI-created profiles start at 500. This setting and request_timeout_s don't limit browser navigation, form submissions or active page checks. Use parallel_workers and security_checks_enabled to reduce browser load:

frontend_dast:
  parallel_workers: 1          # Default: 3

network:
  requests_per_second: 50      # Schema default: 100; UI-created profiles: 500
  request_timeout_s: 10        # Default: 5

Scope Constraints¶

Scan duration and exploration depth should be limited to reduce system impact:

frontend_dast:
  crawling_tuning:
    max_parameterized_url_variations: 2

High-Risk Area Exclusion:

Destructive operations and sensitive areas should be explicitly excluded:

frontend_dast:
  scope:
    crawling:
      blocklist:
        - type: web_page_url
          value: ".*/admin/delete/.*"
          operation: regex
        - type: web_page_url
          value: ".*/payment/process/.*"
          operation: regex
        - type: web_page_url
          value: ".*/data/export/.*"
          operation: regex
        - type: web_page_element_selector
          value: 'button[data-action="delete"]'
        - type: web_page_element_selector
          value: 'a[href*="/admin/"]'
        - type: web_page_element_selector
          value: '[data-analytics-critical="true"]'

    api_testing:
      blocklist:
        - type: rest_api_path
          value: ".*/api/admin/.*"
          operation: regex
        - type: rest_api_path
          value: ".*/api/delete/.*"
          operation: regex

Scanner Identification¶

Scanner requests should be identifiable for allowlisting and monitoring purposes:

network:
  custom_headers:
    user-agent:
      - "EscapeSecurity-ProductionScan/1.0 (Authorized-Scan)"
    X-Security-Scanner:
      - "Escape"
    X-Scan-Purpose:
      - "Production-Safety-Test"

Infrastructure Configuration¶

Firewall and Security System Preparation¶

Prior to production scanning, the following infrastructure configurations should be implemented:

1. IP Allowlisting: Scanner IP addresses should be allowlisted in WAF, CDN, and firewall configurations
2. Rate Limit Exemption: Scanner requests should be exempted from rate limiting rules when feasible
3. SIEM Alert Suppression: Security monitoring systems should have filters configured to suppress alerts from known scanner activities

Pre-Scan Validation¶

Before production scan execution:

• Configuration should be validated in staging environments
• Scans should be scheduled during low-traffic periods
• Application and infrastructure monitoring should be active
• Scan termination procedures should be established

Crawling Behavior¶

Form Input Population¶

Form inputs are populated during scans as part of the standard crawling process, independent of security testing configuration. For the scanner to discover pages and map application functionality, forms must be filled and submitted, multi-step forms must be progressed, and user interactions must be simulated.

Input formats are automatically detected and relevant data is generated to enable effective crawling. This behavior is distinct from the fuzzing and injection testing performed by ACTIVE_PAGE_CHECKS.

API Traffic Analysis¶

API traffic captured during scans can include login, token-exchange, and refresh requests. Active checks against those endpoints can occasionally disrupt authentication and create inconsistent login states.

Exclude sensitive authentication endpoints from API testing with frontend_dast.scope.api_testing.blocklist:

frontend_dast:
  scope:
    api_testing:
      blocklist:
        - type: rest_api_path
          value: ".*/api/auth/.*"
          operation: regex
        - type: rest_api_path
          value: "/api/token/refresh"
          method: POST

Reference: Session Management for comprehensive authentication stability configuration.

Related Documentation¶

• Performance Tuning
• Session Management
• Configuration Reference