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 for XBOW testing 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.

For most pentesting, create a test account with the same permissions as a normal user. This limits the risk of pentesting to the actions a normal user can take.

See Define authentication for testing for implementation details.

Risks of testing with elevated permissions

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

Be aware of these potential issues:

  • Account lockout mechanisms can interrupt testing if they are triggered by authentication probing. If possible, we recommend turning off lockout mechanisms for the duration of your assessment.
  • CAPTCHA systems may block legitimate test traffic.
  • Shared production accounts create audit trail confusion and increase the blast radius of potential issues.

Creating additional accounts for IDOR testing

Insecure Direct Object Reference (IDOR) analysis is available to Enterprise users as a public preview release.

You can improve IDOR testing by creating and defining up to four additional test accounts. These additional accounts are used to build an understanding of the authorization model for the application. Only the first account you configure is used to attack your application.

We recommend you create three test accounts as follows:

  • Credential set 1: the primary test account. This is used to attack the application.
  • Additional account with the same level of priviilege as the primary account. This is used to plan horizontal tests, that is, can the primary account access data owned by another user of the same type.
  • Additional account with a higher level of privilege, such as an administrator role. This is used to plan vertical tests, that is, can the primary account access data owned by a user with enhanced permissions.

You can give IDOR testing further insight into your business logic by sharing the roles and permissions available in your application.

  • For each credential set, use the “Role description” field to describe the expected access for that user.
  • To share more detailed information, use the “Attack strategy” card under “Assessment guidance”. See Attack strategy.

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 the requests it sends. 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
    • By default, XBOW only sends the header to attackable hosts, creating 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 protected 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.

For more guidance on defining your assessment scope, see Scope configuration.

Controlling access to sensitive endpoints

In addition to XBOW’s automatic URL protection, you can manually add URLs to the “Protected URLs” section to define 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 block URLs for truly sensitive operations, see Configure URLs for special treatment.

Limiting impact demonstration

When XBOW finds a significant vulnerability, an impact agent investigates how an attacker could escalate the exploitation further. You can turn off impact demonstration or allow the agent to act more intrusively.

  • Off: Use when your environment cannot tolerate any activity beyond initial detection, or when you only need confirmation that vulnerabilities are present.

  • Moderate: The right default for most production environments and for bug-bounty programs where intrusive demonstration is unwelcome.

  • Deep: Select for a red-team operation. XBOW treats the finding as an entry point and chains across systems, including using captured credentials to authenticate against other services and pivoting into adjacent network resources.

    Only use Deep when you have explicit authorization for cross-system activity. The best fits are dedicated security-testing environments and internal pentests where stakeholders need maximum evidence. If you are unsure whether your environment can tolerate cross-system activity, use Moderate.

Tip: This setting has no impact on the cost of the assessment.

For full demonstration level definitions and examples, see Impact demonstration. For setup steps, see Choose a level for impact demonstration.

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

Related content