A scanner that stops at the login page is testing a different app
Almost everything worth testing lives behind a login, and an unauthenticated scan never sees any of it. Here is what it takes to get in, and how we handle your credentials without spreading them across a fleet.
Contents
Point a scanner at a modern application without logging in and it finds the marketing site, the login form, and a wall. The account settings, the object identifiers, the admin functions and the API that actually touches data are all on the other side of that wall.
A scan that stops there is not a lighter version of a real test. It is a thorough test of a much smaller application that happens to share a domain with the one you care about.
Use credentials you are authorized to use, against systems you are authorized to test, with accounts provisioned for the engagement. Confirm authenticated testing is in scope before you start.
The logins that actually matter
A scanner is only as useful as the login flows it can finish. Static credentials are the easy half: bearer tokens, custom headers, cookies, basic auth. Enough for a lot of APIs, and every tool supports them. Form login and non-interactive OAuth grants are the next step up and still fairly common.
Then there is the half where most tools quietly give up. An SSO or multi-factor login cannot be faked with a stored token. Something has to drive a real browser through the flow and come out the other side holding a session. That is the difference between "supports OAuth" on a comparison table and actually getting a session against a real identity provider.
Your password should not end up on a fleet
The obvious worry about handing a scanner your logins is where those secrets end up, and the honest answer for most tools is "on every machine that runs a scan".
Ours are stored once and encrypted at rest, then resolved by reference when a scan needs them, so the raw secret is not re-sent across the system on every use. Interactive logins are completed by a broker that runs the flow and hands back a short-lived token rather than your password. You give up a login. The machines doing the scanning only ever see a token.
That broker used to reach your login page from our address, which broke a rule we had written down ourselves. We found it in an audit and fixed it, and the whole thing is written up in whose IP address is your scanner using?
The real prize is authorization testing
There is a second reason to bother with any of this. Every credential carries a role label, and once you can log in as several different people you can ask the question that finds the expensive bugs: can this one reach something that belongs to that one?
That is BOLA, BFLA and BOPLA, and it is impossible to test with a single identity no matter how good your payloads are. Full details of what is supported are on the vulnerability engine page. Both capabilities are paid tier and enforced on the server, not in the client.
Add a login and scan the part of the application an anonymous crawler never reaches. Scan behind a login