Production-Safe Scanning¶

Production-safe scanning minimizes infrastructure impact and security alert triggering while maintaining valuable security insights. This configuration is designed to avoid overwhelming infrastructure, affecting end-user experience, or triggering WAF and SIEM alerts.

Complete Configuration¶

The following configuration provides a comprehensive production-safe setup:

mode: read_only

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

  # Resource constraints
  parallel_workers: 1
  max_duration: 30

  crawling_tuning:
    max_parameterized_url_variations: 2
    max_unique_fragments_per_page: 2

  # Scope limitations
  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, the top-level mode: read_only setting is a Crawling-Only option. Crawling focuses on exploring the application structure, including navigation, links, elements and form submissions. No active security testing is performed, only passive analysis of the DOM, browser storage and network traffic. Crawling-Only reduces production impact, but it can still alter application state by submitting forms that create, update, or delete data.

mode: read_only  # Crawling-only for WebApps

This mode is recommended for production environments and can be used for application structure discovery and scan configuration validation.

Explicit Check Selection:

frontend_dast:
  security_checks_enabled:
    - PASSIVE_PAGE_CHECKS
    - NETWORK_CHECKS

Rate Limiting and Traffic Control¶

Request rates should be constrained to minimize server load and prevent rate limiting or WAF triggers:

frontend_dast:
  parallel_workers: 1          # Default: 3

network:
  requests_per_second: 50      # Default: 100
  request_timeout_s: 10        # Default: 5

Scope Constraints¶

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

frontend_dast:
  max_duration: 30  # 30-minute scan window
  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