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 remote scan form is where you define entry URL, scope, required headers, and any authenticated context before sending live traffic.

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

Remote scans require:

• 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.

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

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.

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

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.