WASViking Docs
⌘K
Getting Started

Authenticated scanning

Carry credentials into every analyzer through one shared session, without locking out the test account.

Unauthenticated scans cover the front door. Most of the interesting attack surface lives behind a login. WASViking® ships authenticated scanning as a first-class capability with four auth modes and a shared-session contract that all analyzers honor.

Auth modes

Mode When to use
Form Login Classic login form with username and password. AI Form Autofill detects selectors automatically.
Bearer token REST API with Authorization: Bearer …. Paste the token.
Cookie Opaque session cookie issued by your stack. Paste the cookie value.
Custom header Anything non-standard. Define the header name and value.

Form Login with AI Autofill

WASViking ships an LLM-backed selector detector that:

  1. Loads the login page.
  2. Identifies the username, password, and submit selectors.
  3. Falls back to a headless-browser SPA crawler if the page is JavaScript-only.
  4. Returns a five-verdict compatibility classifier: compatible, captcha, spa, multi-step, uncertain.

The verdict recommends the right auth mode for the scan.

Verdict Recommendation
compatible Use Form Login. Selectors detected, no special handling.
captcha Use Bearer or Cookie. Form is captcha-gated; automation cannot help.
spa Use Form Login with the headless-browser fallback (enabled automatically).
multi-step Use Bearer or Cookie. Login is multi-step; try a session export.
uncertain Try Form Login first; switch to Bearer or Cookie if it fails.

Shared session contract

When a scan picks Form Login, the platform authenticates once and shares the resulting cookies with every analyzer in the scan. SQL Injection, XSS, JWT, GraphQL, SOAP, WebSocket, and the injection-class checks all share one session.

The practical effect: a multi-analyzer scan looks like a single authenticated user to the target, so it stays well clear of typical anti-brute-force thresholds.

For Bearer, Cookie, and Custom Header modes, WASViking carries the credential through every request via the same shared-session mechanism. You paste it once at scan configuration; it is encrypted at rest and never logged in plaintext.

Multi-step login

If the login is multi-step (email page, password page, MFA, etc.) and the AI classifier returns multi-step, the best path is:

  1. Authenticate manually once in your browser.
  2. Export the session cookie or Bearer token using your dev tools.
  3. Paste it into WASViking as Cookie or Bearer mode.
  4. Document the token's lifetime so the scan window fits inside it.

Token refresh

Long-running scans against short-lived tokens fail. Two approaches:

  • Use a longer-lived service account for scanning where your stack allows it.
  • Schedule shorter scans during a window your token covers. Scan templates let you split a profile across multiple shorter runs.

What never leaves the platform

WASViking treats authentication material as sensitive:

  • Credentials are encrypted at rest using a tenant-scoped key.
  • Credentials are never written to logs.
  • The Sentinel gRPC service redacts proto, job, and response payloads so internal-target cookies do not appear in operator logs.
  • API keys are masked in the UI after creation.

Validating an authenticated scan worked

In the scan report, look at the Coverage tab. An authenticated scan should show:

  • Coverage of routes under /admin/, /account/, or whatever your authenticated area is.
  • Findings tagged with an auth_context: form_login or similar marker.
  • A higher count of discovered URLs than an unauthenticated scan against the same target.

If you see none of these, the session probably did not stick. Open the scan log and check the AI Form Autofill verdict.