Point a scanner at a modern app without logging in and it sees the marketing site, the login page, and a wall. Everything that matters, the account settings, the object IDs, the admin functions, the API that actually handles data, lives behind the login. If your scanner cannot authenticate, it never touches the surface where broken authorization, injection, and data exposure actually happen. This post is about testing that surface: the login types that matter, and how Crossfyre handles them without turning your credentials into a liability.
Authenticated scanning uses credentials you are authorized to use, against systems you are authorized to test. Use accounts provisioned for the engagement, and confirm authenticated testing is in scope before you start.
Why unauthenticated scans miss the real bugs
Coverage is the whole game. An unauthenticated crawl reaches a tiny fraction of the app: the public pages and the login form. The authenticated surface, the part gated behind a session, is usually an order of magnitude larger and contains almost all of the sensitive functionality. A scan that stops at the login page is not a lighter version of a real test; it is testing a different, much smaller application.
The login types that matter
Real apps authenticate in more than one way, and a scanner is only as useful as the login flows it can actually complete. Crossfyre supports seven auth types across two families:
- Static credentials: bearer tokens, custom headers, cookies, and HTTP basic auth. Simple, and enough for many APIs.
- Form login: submit a username and password to a login form and capture the resulting session.
- Non-interactive OAuth: client-credentials and password grants, run without a browser.
- Interactive OAuth and SSO: authorization-code flows and SSO / MFA logins that need a real browser to complete.
The interactive types are the ones most tools give up on. An SSO or MFA login cannot be faked with a static token; something has to actually drive the browser through the flow and capture the session at the end. That is the difference between "supports OAuth" on a feature list and actually getting a session against a real identity provider.
Your credentials should never touch the fleet
The obvious worry with handing a scanner your logins is where those secrets end up. Crossfyre is built so they never spread. Interactive logins are completed by a headless auth broker that performs the flow and returns only a resolved token, not your password. A credential is stored once, encrypted at rest, and resolved by reference at scan time, so the raw secret does not re-transit the system every time a node needs to authenticate. You hand over a login; the fleet only ever sees a short-lived token.
- Encrypted at rest. Stored secrets are encrypted, not sitting in plaintext.
- Resolved by reference. The raw secret is not re-sent across the system on every use.
- Tokens, not passwords. Interactive flows return a session token; your password stays with the broker.
Authenticated scanning is what unlocks authorization testing
There is a second reason authenticated scanning matters: it is the foundation for testing authorization. Every credential you add carries a role label, admin, user A, user B, and that is exactly what an authorization test needs to replay each endpoint as each identity and catch BOLA, BFLA, and BOPLA. Log in as several identities, and you can ask the question that finds the highest-value bugs: can this user reach something they should not?
For the full picture of what is supported and how credentials are handled, see authenticated scanning. Authenticated scanning and authorization testing are paid-tier capabilities, enforced server-side.
Add a login, scan behind it, and test the surface an unauthenticated scan never sees.
Start free