Skip to content

#142 · Improved Identification of Escape DAST Traffic

Escape DAST now makes it simpler to identify and securely whitelist scan traffic in your WAF.

To ensure your application remains accessible to Escape scans, you now have three supported options:

Screenshot 2025-12-24 at 14.05.31.png

  1. Whitelist Escape Public Locations IPs

  2. Use a Private Location

    → Private Location documentation

  3. Whitelist the Sec-Escape-User header in your WAF

    → Firewall configuration documentation

Sec-Escape-User Header for Secure WAF Whitelisting

As mentioned, all HTTP traffic generated by Escape DAST now automatically includes the Sec-Escape-User header.

This header identifies the Escape user who initiated the scan, making it easier to recognize legitimate DAST traffic in logs and WAF rules.

To configure custom HTTP headers and include a shared secret following the example configuration below:

network:
  sec_escape_user: true
custom_headers:
  X-MyCustomHeader:
    - secret123

Full documentation is available here.

For backward compatibility:

  • The x-escape-user header is still sent in API traffic and iin Web App DAST only if it was previously enabled

More details are available in the DAST configuration documentation.

⚠️ Security reminder: This can be used to identify HTTP traffic coming from Escape, but make sure to also verify the IP as headers can easily be spoofed by anyone!

With this new configuration:

  • Escape continues to send the default Sec-Escape-User header.
  • A custom header with a secret value is added to every DAST request.
  • Your WAF can allow traffic only when both the trusted IP range and secret header are present.

Why it matters

  • Fewer blocked scans in WAF-protected environments
  • Stronger verification of legitimate DAST traffic
  • Simple, flexible setup without weakening security controls

This update gives security teams greater control and confidence when running Escape DAST against production-like environments.