Active Test Targets
An active test needs to know more than a domain name: which URL to start from, which scan mode to run, and, if the interesting parts of your application are behind a login, how to authenticate. That configuration is an active test target, and it lives on the Active DAST tab of the Pentesting page.
A black-box scan needs none of this — it runs straight against a verified domain from the Domains tab.
A target is saved once and reused for every run against it, which is what makes results comparable from one assessment to the next.
Before you start
The target's domain must already be verified. See Domain Verification.
Create a target
- Open Pentesting and select the Active DAST tab.
- Choose the verified domain the target belongs to.
- Enter the target URL — the address the test should start from.
- Choose the scan mode: Quick, Standard or Deep. See Scan Modes.
- Choose an authentication method, if the application needs one.
- Save.
Choosing the target URL
Point the URL at the entry point of the application you want tested, not at a marketing page:
| Good | Why |
|---|---|
https://app.example.com |
The application itself |
https://example.com/dashboard |
The authenticated area's entry point |
https://api.example.com/v1 |
An API root |
The URL must be publicly reachable and its hostname must sit inside the verified
domain. Private, loopback, link-local and internal addresses are refused, in
every encoding of them, and a URL outside the verified domain is rejected when
you save the target rather than silently ignored at run time. Use HTTPS: http
is accepted, but testing an application over plaintext tells you less and
exposes the credentials you supply.
If the target cannot be reached when the run starts, the run fails and says so. An unreachable application is never reported as a clean one.
Do not put credentials in the URL. Use the authentication fields below — they are encrypted at rest, and a URL is not.
Authentication
Most of an application's risk is behind its login. Without credentials, an active test can only assess the parts an anonymous visitor can reach, which is usually a small fraction of the real attack surface. Supplying authentication is the single biggest improvement you can make to the quality of a report.
| Method | Use when | You provide |
|---|---|---|
| None | The application is public, or you only want the anonymous view | Nothing |
| Basic | The application uses HTTP basic authentication | Username and password |
| Bearer | The application or API uses a token in the Authorization header |
The token |
| Cookie | The application uses a session cookie | The cookie value |
How credentials are handled
- They are encrypted before they are stored.
- They are released only to the isolated environment that runs your scan.
- Request and response headers carrying them are redacted from the evidence saved in your report, so a report can be shared without leaking a session.
- Selecting None and saving deletes the stored credentials — it does not keep quietly using the old ones.
Recommended practice
Create a dedicated test account rather than using a real one, give it the permissions of an ordinary user, and populate it with data you do not mind seeing changed. An active test submits forms and manipulates parameters; it behaves like a user who tries everything.
warningAn active test sends real traffic and may create, modify or delete data that the account you supply is able to create, modify or delete. Prefer a staging environment for the first run against a new application, and avoid supplying an administrative account.
Rotating a token or cookie
Session cookies and bearer tokens expire. If a run comes back with far fewer findings than the previous one, and the application is behind a login, an expired credential is the most likely explanation. Save the target again with a fresh value and re-run.
Enabling and disabling
A target can be disabled without being deleted. A disabled target cannot be run — useful for freezing an environment during a release or an incident without losing its configuration and history.
Deleting the target's domain deletes the target with it.
Starting a run
Start the run from the target's row. Codity validates the whole run before anything is charged — an unverified domain, a disabled target, or an assessment already in flight is refused up front. The mode that runs is read from the saved target, so the price you are quoted is the price of the test that executes.
While a run is in progress, the Reports tab keeps itself up to date. You can close the browser; the scan continues.
infoOne assessment runs at a time per organization. Wait for the current one to finish before starting the next.
