Target protection
- Private preview
Target protection sets the boundary for what XBOW may do to your asset during an assessment. Every command an XBOW agent proposes passes a safety check before it runs, and target protection determines which rules that check applies.
Note: Target protection is in private preview and is not available to all organizations. If the “Configuration check” page does not show a “Testing depth” section when you configure an assessment, contact your XBOW representative. Without access, your assessments run at the default level, Standard.
Standard and Permissive
You can choose one of two levels for each assessment.
| Level | What XBOW does | Best for |
|---|---|---|
| Standard (default) | Avoids actions that could disrupt your asset or lock the credentials it depends on. Some safe actions are blocked as a result. | Production, anything customer-facing, a first assessment of a new asset, and change-control processes that need the smallest possible impact. |
| Permissive | Allows a wider set of actions to prove impact, accepting known side effects such as changed data. | Staging and pre-production assets that you can restore. |
Standard is the initial default. Console remembers the level you saved for future assessments on the same asset, so an asset last configured with Permissive continues to use permissive unless you change it.
What both levels always block
Both levels apply a common set of rules. These limits hold whichever level you choose:
- Data leaving your boundary: Anything XBOW finds can only be sent to XBOW’s own endpoints.
- Credentials you did not supply: When XBOW logs in, it uses only the usernames, passwords, and tokens you provide. It does not guess passwords or try default or leaked credentials against your accounts. If your credentials fail, the run reports the failure rather than trying something else.
- Destroying or changing data: Commands that delete, drop, truncate, or update database records or schema are blocked, as are password resets, account deactivation, and destructive cloud operations.
- Availability impact: Actions that resemble a denial-of-service attempt are blocked, such as request floods, heavy queries designed to exhaust a database, scan storms, large downloads, and recursive fetches.
- Moving beyond the finding: If XBOW retrieves cloud credentials while proving a vulnerability, it does not use them to reach your cloud control plane or other services.
What changes between the two levels
Permissive changes the verdict on a short list of behaviors across four vulnerability classes. Everything else is identical between the two levels. No setting turns the safety check off.
SQL injection
| Behavior | What XBOW could do | Standard | Permissive |
|---|---|---|---|
| Run commands on the database host | Use the database engine to run operating-system commands, for example xp_cmdshell, stepping outside the database onto the machine. | Blocked | Allowed |
| Write files to the database host | Write a file onto the server through the database, for example INTO OUTFILE. This changes state on the host. | Blocked | Allowed |
| Pull full tables | Read many rows at once rather than one proof value. Standard caps how much data XBOW may extract and will not dump whole tables. | Capped | Uncapped |
Both levels allow the work that proves the vulnerability: confirming the injection point, listing table and column names, checking the database version and current user, reading a single proof value, and reading a file from the database host.
Remote code execution
| Behavior | What XBOW could do | Standard | Permissive |
|---|---|---|---|
| Run an exploit chain | Chain a deserialization or sandbox-escape bug to reach code execution. | Blocked | Allowed |
| Write a file or web shell | Upload a web shell or write a file into the web root. This changes state on the host and leaves something behind. | Blocked | Allowed |
| Change an asset setting | Alter application configuration, flip a feature toggle, or add an allowlist entry. | Blocked | Allowed |
Both levels allow the work that proves code runs: a harmless probe such as a timed delay, checking the context it runs in, reading a single proof value, and reading a system file such as /etc/passwd.
Server-side request forgery (SSRF)
| Behavior | What XBOW could do | Standard | Permissive |
|---|---|---|---|
| Broad internal port scan | Sweep a whole subnet or a large port range through the vulnerable request, instead of checking a handful of likely services. | Blocked | Allowed |
| Trigger a privileged internal action | Call an internal admin API or change an application setting through the vulnerability, rather than only reading. | Blocked | Allowed |
| Switch to a non-web protocol | Use the vulnerability to speak something other than HTTP, for example a crafted Redis or SMTP request. This can escalate to running code internally. | Blocked | Allowed |
Both levels allow XBOW to confirm the vulnerability and show its reach. This includes proving the request leaves your asset, defeating filters, reaching internal addresses, and probing specific internal services. It also includes reading internal admin pages and configuration, reading cloud instance metadata, and retrieving cloud credentials as evidence.
Cross-site scripting (XSS)
| Behavior | What XBOW could do | Standard | Permissive |
|---|---|---|---|
| Self-spreading payload | Store a payload that spreads on its own into other users’ content, the way a real XSS worm would. The payload stays inside your asset but can reach people beyond the test account. | Blocked | Allowed |
Both levels allow XBOW to confirm the injection point, identify how the payload would execute, and prove that script actually runs. They also allow XBOW to read a value from the page to show impact, capture a session cookie, and show a stored payload firing in an administrator’s view.
Permissive makes changes on your asset, so use it only on an asset you can restore.
Target protection and impact demonstration
The two settings work together in the “Testing depth” section:
- Target protection sets the boundary for the whole assessment.
- Impact demonstration sets how hard XBOW pushes to prove a finding after it finds one. See Impact demonstration.
If you choose Deep impact demonstration with Standard target protection, Console shows “Limited by Standard protection”. Console skips Deep steps that need a wider set of actions. To allow the full depth of Deep, choose Permissive on an asset you can restore.