Protecting assets during XBOW testing

Penetration testing exercises real functionality in your asset, which means it can trigger real consequences. XBOW provides multiple layers of protection, each addressing different risks. This article describes each layer and how to configure it.

To decide where to test and which settings suit your risk tolerance, see Testing your asset safely.

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 as a public preview release.

Each assessment has a primary credential set that is used for asset discovery and all attack methods. You can enable IDOR testing by creating and defining up to four additional test accounts. These additional accounts are used only to plan and perform IDOR-specific attacks. For the steps to add the accounts to a configuration, see Work with multiple credential sets.

We recommend you create three test accounts as follows:

  • Credential set 1: The primary credential set. This account should have an administrator role to help XBOW perform broader discovery of your asset, identify user privileges, and create resources needed for IDOR testing.
  • Credential set 2: An account with a lower level of privilege than credential set 1. This privilege gap allows XBOW to perform vertical tests, which check if an account can access data owned by a user with enhanced permissions.
  • Credential set 3: An account with the same level of privilege as credential set 2. These accounts let XBOW plan and execute horizontal tests, which check if an account can access data owned by another user of the same type.

Each credential set requires a role description to share the expected access for that user. You can also share more detailed information about your business logic using the Attack strategy card under “Assessment guidance”. See Attack strategy.

After you create and configure all of your accounts, confirm that Perform discovery and non-IDOR attacks with this account is selected for credential set 1.

Guiding your assessment

To customize XBOW’s testing approach for your asset, you can click the cards in the “Assessment guidance” section to clarify the attack surface, priorities, attack strategy, and validation methodology XBOW should use. This guidance can include uploaded files, free text, and feature selection.

Once you save your input, XBOW automatically extracts general guidance and safety guidance. General guidance is used throughout testing, while safety guidance is used specifically to help evaluate whether planned testing actions should proceed.

For detailed information on assessment guidance, see Guiding XBOW testing for experts.

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 web application if XBOW’s IP ranges are compromised
  • Disable WAF during testing: The simplest option, but creates security risks:
    • Exposes your web 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 assets are not standalone systems. They rely on resources hosted on other domains, use telemetry services, or third-party authentication. XBOW needs access to all the sites that your asset 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 protection 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 the target 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 resources 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. Blocking an endpoint that XBOW needs to log in or to keep a session alive causes an authentication failure that pauses the assessment. Use Auth-only for credential and session endpoints so XBOW can reach them without attacking them, and only use Blocked 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 when you want to demonstrate the realistic worst-case business impact of a finding, such as account takeover or privilege escalation. XBOW treats the finding as an entry point, chains weaknesses, and follows attack paths. It can run read-only network enumeration from its vantage point to identify reachable systems, but it is instructed not to actively pivot into or compromise adjacent systems.

Deep is more intrusive than Moderate, so use it where you are comfortable with chained testing against the asset, such as dedicated security-testing environments and internal pentests where stakeholders need maximum evidence. If you are unsure, use Moderate. Get explicit authorization before you choose Deep with Permissive target protection, because Permissive allows wider changes to the asset. See Target protection.

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

By default, XBOW can test your asset at any time, but you can also set an allowed testing window using any of the following options:

  • Business hours: Actively monitor test traffic and respond quickly to issues.
  • Off-hours: Minimize impact in production systems with active users during business hours.
  • Custom: Build a flexible testing schedule to meet your specific needs.

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. See Set request rate limits for implementation.

After your first assessment, adjust based on the observed performance. For recommended rates for different situations, see Match your settings to your risk.

Monitoring performance

Consider asking your operations team to monitor your asset 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

XBOW also monitors the asset’s health during the assessment and automatically throttles or pauses testing if the asset struggles. See Monitor assessment and Target health.

Related content

Was this helpful?