Remote target scans

Remote scans actively probe a running web application, API, or SaaS endpoint. Use them only for systems you own or have explicit permission to test.

Remote scans are for vulnerabilities that require runtime behavior: routing, sessions, deployed configuration, API gateway behavior, redirects, server-side fetching, CORS, role state, and real HTTP responses.

The first wizard step defines the authorized target boundary before any access details or advanced scan settings are reviewed.

Authorization required

Remote scans send real HTTP payloads for classes such as SQL injection, XSS, SSRF, path traversal, and authentication flaws. Unauthorized scanning may violate computer-misuse laws and program rules.

Inputs

The Scope step requires:

• an entry URL
• scope hosts
• an authorization confirmation

If you do not enter scope hosts, ZeroQuarry uses the entry URL host. Scope hosts limit where agents should send probes.

Treat scope hosts as a safety control, not documentation. Add every approved host explicitly when a workflow crosses subdomains, APIs, or CDN-backed routes.

The Access step is optional for public targets. It collects required identification headers, cookies or API authentication, HTTP Basic credentials, and form-login details in separate controls.

ZeroQuarry Cloud rejects loopback, link-local, RFC1918, and internal-DNS targets. Enterprise accounts can test authorized internal applications from a customer-controlled network by selecting an approved private runner for the project. The private runner changes reachability; it does not relax the authorization or scope requirement.

When remote scans are the right tool

Use a remote scan when you need to test:

• IDOR and authorization flaws in a running application
• SSRF reachability and outbound request behavior
• XSS, SQL injection, path traversal, and parser payload handling
• API gateway or reverse-proxy behavior
• deployed headers, redirects, CORS, cookies, and session state
• bug-bounty or staging targets where active probing is authorized

Prefer source or binary scans when you are not authorized to send traffic, the target is fragile, or you only need static evidence.

Required headers

Some bug bounty programs require identifying headers on every request, such as X-HackerOne-Handle, X-Bugcrowd-Ninja, or X-Researcher.

Use Required headers for these values. ZeroQuarry attaches them to every probe, including form-login setup. Required header names and values are shown in scan logs so you can verify compliance.

Authentication and access

Remote scans can attach authentication context to probes:

Method	Use it for
Cookies	Browser session cookies copied from developer tools.
Custom headers	Bearer tokens, API keys, or app-specific headers.
HTTP Basic auth	Targets protected by Basic auth.
Form login	A one-time login request that obtains session cookies before probing.

Public targets can skip access details. Authenticated assessments can add only the mechanism required by the approved test account.

Sensitive authentication values are redacted from scan logs. They are still sent to the LLM agent as scan context and to the target as HTTP headers or cookies. Use authentication only with LLM providers and target environments you are comfortable exposing to that data.

Authenticated testing strategy

For authorization bugs, one credential is often not enough. Consider running separate scans for:

• unauthenticated user
• low-privilege user
• normal customer or tenant admin
• internal support role
• cross-tenant test accounts

Name and tag each scan so the report makes the tested role obvious. Never use production administrator credentials unless that is explicitly approved for the test.

Safe scoping

Before queueing a remote scan:

• use a staging or test environment when possible
• include every in-scope host explicitly
• exclude third-party infrastructure that is not in scope
• add required program headers
• avoid production-only credentials unless they are approved for testing
• use notes to describe fragile endpoints, rate limits, or program rules

Scan settings

The Review step exposes focus, model, coordinator-budget, Batch API, HackerOne, independent-review, notification, and execution controls when the account tier and workflow mode permit them. Guided modes may apply entitled review defaults without showing each advanced control.

For internal targets, the scan form also shows Execution environment when the project allows a compatible private runner pool. Private jobs remain pinned to that pool and never fall back to ZeroQuarry Cloud automatically.

Review remote findings

Remote findings should be reviewed for:

• exact request sequence
• target account, role, and environment
• whether payloads were destructive or read-only
• response evidence and status codes
• whether required headers were attached
• whether a source or binary scan can explain the root cause

For externally reported issues, move from the finding to External disclosure workflow.

Example notes

Authorized staging target. Keep probes non-destructive. Focus on IDOR in
/api/accounts/* and SSRF in the import-url feature.

Bug bounty target. Required headers are configured. Only test app.example.com
and api.example.com.