Protecting targets during XBOW testing

Penetration testing exercises real functionality in your application, which means it can trigger real consequences. Understanding how to protect your targets while still getting comprehensive security testing is essential for safe and effective assessments.

XBOW provides multiple layers of protection, each addressing different risks. The effectiveness of your protection strategy depends on choosing appropriate settings for your testing environment and risk tolerance.

Using a dedicated test account

The account you provide to XBOW determines what functionality can be tested and what damage could potentially occur. Use dedicated test accounts with realistic permissions for the features being tested, avoiding unnecessary privileges.

Standard user accounts are best for testing user-facing functionality, as they limit risk to what a normal user can do.

Elevated permissions are sometimes necessary to test administrative features or restricted functionality. However, these accounts require careful endpoint blocking to prevent unintended actions.

Be aware of these potential issues:

  • Account lockout mechanisms can interrupt testing if triggered by authentication probing.
  • CAPTCHA systems may block legitimate test traffic if enabled.
  • Shared production accounts create audit trail confusion and increase the blast radius of potential issues.

See Define authentication for testing for implementation details.

Allowing access through your firewall

Your web application firewall (WAF) protects your application from malicious traffic. During security testing, you need to allow XBOW’s intentionally malicious payloads through while maintaining security for other traffic.

Access control options (from most to least secure):

  • Custom bypass headers: XBOW includes a header you define in every request. Configure your WAF to allow requests with this header. This is the most secure option because:
    • Only XBOW knows the header value
    • Easy to detect and distinguish XBOW traffic in logs
    • Simple to enable and disable without infrastructure changes
    • Minimal security exposure
  • IP address allowlisting: Configure your WAF to allow traffic from XBOW’s IP ranges. More secure than disabling the WAF entirely, but has limitations:
    • Requires infrastructure changes to allowlist rules
    • All traffic from those IPs is allowed, not just XBOW
    • May expose your application if XBOW’s IP ranges are compromised
  • Disable WAF during testing: The simplest option, but creates security risks:
    • Exposes your application to all traffic during testing
    • Creates a window of vulnerability
    • Only appropriate for non-production test environments

Your choice depends on whether you’re testing production or an isolated test environment, your ability to configure custom WAF rules, security team requirements and approval processes, and your risk tolerance for temporary security exposure.

See Configure your server to allow XBOW requests for implementation steps.

Excluding domains and sensitive endpoints from attack

Most web applications are not standalone systems. They rely on assets hosted on other domains, use telemetry services, or third-party authentication. XBOW needs access to all the sites that your web application depends on, but you do not want to attack third-party sites. Domain scoping allows you to control what is included in the assessment.

Even within domains you want to test, some functionality should never be exercised during automated testing. URL blocking provides a second level control over which endpoints XBOW can access within attackable domains.

Note: Domain scopes and blocked URLs cannot be changed after the assessment starts.

Defining the scope

After XBOW checks the configuration for your assessment, it identifies the domains your application uses during authentication and discovery checks. All domains discovered are listed in the “Scope” section of the “Configuration check” page.

For each domain, XBOW suggests whether the domain should be attacked, visited without attack, or blocked from access during testing. This setting determines whether the domain is included in testing and how it is treated.

Review each domain setting carefully. While you do not want to attack third-party domains, you should usually allow XBOW to visit them to get assets needed for your site to run correctly. If you block domains that your site depends on, this often leads to poor test results.

Controlling access to sensitive endpoints

You can limit access to endpoints within any of the attackable domains by adding the URLs to the “Blocked URLs” section and defining how they should be treated.

  • Auth-only: XBOW can access these endpoints for authentication purposes but will not attack them. Use for credential management endpoints like password reset or profile update pages.
  • Blocked: XBOW cannot access these endpoints at all. Use to block any irreversible operations that cannot be easily rolled back, such as account deletion or payment processing.

Over-cautious blocks limit the effectiveness of testing. Only add blocked URLs for truly sensitive operations, see Configure URLs for special treatment.

Defining test windows

Setting a limit on when XBOW can test provides additional control over operational impact and enables human monitoring.

  • Use Business hours only when you want to actively monitor test traffic and respond quickly to issues.
  • Choose Off-business hours only to minimize impact in production systems with active users during business hours.
  • For test environments, use Anytime to get results quicker.

See Configure test windows for configuration.

Limiting request rates

Security testing generates a lot of requests. Setting a rate limit protects your infrastructure from being overwhelmed during testing. This is especially important for production sites where testing could have an impact on real users.

Higher rates provide faster results but increase infrastructure load, while lower rates reduce impact but take longer to complete.

Note: Rate limits cannot be changed after the assessment starts.

Choosing an appropriate starting rate

For your first assessment, start with a conservative limit (for example, 250 requests/second) to establish baseline behavior. If previous assessments caused performance issues, reduce rates for subsequent runs. See Set request rate limits for implementation.

  • Recommended starting point: 250 requests per second (RPS)
  • Conservative approach: 100-150 RPS for applications with known performance constraints
  • Aggressive approach: 500+ RPS for robust test environments with proven capacity

After your first assessment, adjust based on the observed performance.

Monitoring application performance

Consider asking your operations team to monitor your application during the first assessment to establish baselines and identify optimal settings.

Key metrics to track:

  • Server response times and latency
  • Error rates and types (4xx, 5xx responses)
  • Resource utilization (CPU, memory, database connections)
  • Application performance monitoring (APM) alerts
  • Any performance anomalies or degradation