Skip to main content

Username and password

Pick Username and password when your app has a traditional HTML login — a page with a username and password field that posts to a server and sets a session cookie (or returns a token stored in localStorage). The dashboard label is Username and password; the underlying CLI / YAML strategy name remains form.

When to use

  • Classic server-rendered apps with a /login page.
  • SPAs where a test user can sign in with a form.
  • Anywhere a password-based flow exists and you have a dedicated test account.

What you'll need

  • Login URL — the page that shows the form (not the form action endpoint). If the form is on the same URL you're scanning, tick the "Login URL is the same as target URL" checkbox and skip this field.
  • Username and Password — a dedicated scan account.
  • Optional: any Pre-Auth Cookies / Headers / Local Storage values the login page requires.

Dashboard

In Create Scan → Step 2, select Authenticated Scan, then pick Username and password.
Enter Login URL (or tick "Login URL is the same as target URL" if it matches your scan target), then Username and Password.
Fill Pre-Auth Cookies / Headers / Local Storage if your login page needs them (CSRF tokens, tenant selector cookies, SPA bootstrap values).
Click Next to continue to crawling & discovery.

The scanner navigates to the login URL, fills the form, submits it, and uses the resulting session for every subsequent request.

CLI

shadownet scan https://app.example.com \
--auth form \
--login-url https://app.example.com/login \
--username "$SCAN_USERNAME" \
--password "$SCAN_PASSWORD"

$SCAN_USERNAME and $SCAN_PASSWORD come from your shell / CI secret store — never hard-code them.

levo-dast.yml

auth:
strategy: "form"
login_url: "https://app.example.com/login"
username: "${SCAN_USERNAME}"
# password → --password CLI flag or SCAN_PASSWORD env var, NOT YAML
Passwords never go in YAML

password, raw cookie values, and tokens are on the YAML blocklist. Use --password / --token flags or environment variables at runtime.

Pre-Auth values

Common reasons to set these for form login:

  • CSRF cookie seeded by a GET to the login page — add it as a Pre-Auth Cookie.
  • Tenant or region header required by the API gateway — add as a Pre-Auth Header.
  • SPA boot flags stored in localStorage — add as Local Storage Items.

Verifying the login worked

After a scan starts, the scan detail page shows an Auth status. If login failed, the most common causes are:

  • Wrong login URL — pointing at the app home page rather than the form page.
  • CSRF token that rotates per request and needs to be extracted from the form — file a support ticket for a custom strategy.
  • MFA / CAPTCHA — a password form alone isn't enough. Use AI-assisted login or disable MFA for the scan account in non-prod.
  • Account locked after repeated scans — rotate the password and clear the lock.

Next

Was this page helpful?