The test account for the active scan
1 min read
Why a test account?
Some vulnerabilities only exist from a logged-in user's point of view; the classic case is BOLA/IDOR: an endpoint that checks a session exists, but never that the session actually owns the requested resource (for example `GET /api/invoices/1234` reachable by any logged-in user, not just invoice 1234's owner). Without a test account, these are invisible to the scan.
Use a dedicated account, never a real one, with throwaway data. The active scan performs real actions on its behalf (form submissions, RPC calls): a real account would expose real data in the results.
What the form asks for
In the "Active scan" panel, in login mode (the default option, not an unauthenticated one you'd need to opt out of): login URL (optional), username/email, password. Running a scan with no test account is still possible, but it's an explicit choice: the matching box is never pre-checked for you.
"Save" is separate from "Run scan"
The credentials form feeds the scan you're currently starting, whether you save it or not. A separate button, "Save for auto rescan", stores those credentials server-side: that's specifically what the automatic weekly rescan (the scheduler) will use the following week, independent of whatever you type into the form afterward.
No classic login form?
If your app has no standard email/password form (OAuth only, SSO...), use a session cookie or a token instead. See the dedicated article, an "advanced" option reachable from that same panel.