Authentication Overview
Most real applications hide their interesting surface area behind a login. DAST Scanner supports four authentication strategies — pick the one that matches how your app expects callers to prove who they are.
Decision tree
| If your app is… | Use | Why |
|---|---|---|
| Public, no login (marketing site, open API) | None | Nothing to authenticate — scan the whole surface. |
| An API that accepts a Bearer/JWT/API key header | Token | The scanner attaches one header to every request. |
| A web app with a username + password form | Form | The scanner logs in once, captures the session, and replays it. |
| Complex, multi-step, or you don't want to encode selectors | AI-driven (Beta) | An LLM navigates the login flow for you. |
Every strategy is selectable in the Create Scan dialog (Step 2) and via the CLI / levo-dast.yml.
Public apps and open APIs.
Bearer tokens, JWTs, API keys.
HTML login forms.
LLM-guided login discovery.
Dashboard vs CLI vs YAML
The same four strategies exist everywhere:
| Strategy | Dashboard (Step 2) | CLI flag | levo-dast.yml (auth.strategy) |
|---|---|---|---|
| None | None card | --auth none | none |
| Token | Token card | --auth token --token $TOKEN | token |
| Form | Form-based Login card | --auth form --username … --password … --login-url … | form |
| AI-driven | AI-driven card | --auth ai | ai |
Pre-Auth values — shared across strategies
Three fields on the Authentication step apply regardless of which strategy you pick. Use them when your app needs state in place before the login request is sent:
- Pre-Auth Cookies — CSRF tokens, tenant selectors, feature flags read by the login page.
- Pre-Auth Headers — tenant headers (
X-Tenant-Id), API gateway tokens,Accept-Language. - Local Storage Items / Local Storage Items (Base64) — SPA bootstrap data read on first load, or base64-encoded blobs.
Passwords, bearer tokens, raw cookie values, and API keys always come from a CLI flag or environment variable — never the YAML file. See the secrets policy.
Picking a test account
- Create a dedicated scan account in each environment — don't reuse a developer's account.
- Give it the same role as a normal user (not admin) unless you want admin-only paths tested.
- Expect the scan to submit forms, trigger emails, and change state. Keep it off production where possible — see Scanning production safely.