An automated security scanner can generate traffic, exercise endpoints, and preserve evidence about a remote system. That capability is useful only when the platform can establish that the customer is authorized to test the destination.
A checkbox saying “I have permission” records an assertion. It does not constrain where the scanner can connect.
Target verification belongs in the execution boundary.
Prove Control Outside the Application
Rorix uses a DNS TXT challenge to verify control of a target domain. DNS is useful here because the proof exists outside the Rorix account and must be placed by someone with control over the domain's configuration.
The verified domain then defines the scope from which stored targets may be created. A target can refer to the verified host or an allowed subdomain, but not an arbitrary URL supplied when a run begins.
This separation matters. Account access authorizes use of the product; domain verification authorizes the network destination.
Verification Is Not Permanent
A domain can change hands. A DNS record can be removed. Configuration can drift between the day a target is created and the day a scheduled job runs.
Rorix therefore rechecks domain verification and destination safety immediately before dispatch. If the proof is gone, the run does not proceed.
Schedules follow the same rule. A skipped execution should be recorded with its reason rather than disappearing or testing an unverified destination because it was valid last month.
Validate Every Destination, Including Redirects
Checking the first URL is insufficient. Public endpoints can redirect to private addresses, link-local services, cloud metadata endpoints, or other destinations outside the verified scope.
A safe platform validates:
- the original scheme and hostname;
- resolved IP addresses;
- every redirect destination;
- allowed ports;
- whether the destination remains inside the verified domain boundary.
Private, loopback, link-local, multicast, documentation, and other reserved ranges should be rejected. Production runs should use a narrow port policy unless a broader scope has been explicitly designed and authorized.
These controls protect both the target owner and the scanning infrastructure from becoming an SSRF relay.
Store the Target, Not Just the URL
An API that accepts any URL with every scan request makes authorization difficult to review. A stronger workflow creates a target record that binds together:
- the verified domain;
- the exact public URL;
- optional OpenAPI configuration;
- enabled state;
- authorization context;
- schedules and prior runs.
Manual, project, scheduled, and CI runs can then refer to the same target identity. They do not need separate interpretations of what is in scope.
This is why Rorix CI accepts an existing verified target ID instead of an arbitrary command-line URL.
OpenAPI Documents Need Scope Too
An OpenAPI document can reference servers and external resources. Treating the document as trusted input can expand a scan beyond the verified application.
Rorix accepts an inline document or an in-scope document URL, rejects external references in its safe profile, and limits operation testing to the stored target's boundary. The document describes possible coverage; it does not grant additional network authority.
Authorization and Intensity Are Different Controls
Proving control of a target does not justify unlimited testing. Request counts, concurrency, response sizes, redirects, ports, methods, and total duration still need explicit bounds.
Conversely, a “safe” request budget does not make an unverified target acceptable. Scope and intensity are independent parts of the safety model.
Make the Boundary Visible in Results
A report should state which target was verified, which engines ran, which requests were attempted, and where coverage was skipped or incomplete. That evidence helps operators distinguish a tested boundary from an assumed one.
The Rorix Pentesting documentation details target verification, destination validation, and the current safe profile. You can also review the Pentesting product overview and sample report.
The scanner is not the first step of a pentest platform. The first step is proving where it is allowed to operate—and making that proof part of every run.