# 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: ```yaml 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. ```yaml 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**: ```yaml 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: ```yaml 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: ```yaml frontend_dast: crawling_tuning: max_parameterized_url_variations: 2 ``` **High-Risk Area Exclusion**: Destructive operations and sensitive areas should be explicitly excluded: ```yaml 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: ```yaml 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 > [!WARNING] > > **Production Scanning Risks** > > Production scanning carries inherent risks regardless of configuration conservativeness. Coordination with operations, security, and development teams is required before production scan execution. ## 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`: ```yaml 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]()