Skip to main content

Browser session

Pick Browser session when you already have a logged-in browser session and want to hand it to the scanner directly — instead of giving it credentials and asking it to log in itself. The scanner reuses the session as-is and skips the auth phase entirely, so it never sees the username, password, or any step of the login flow.

When to use​

  • The scan account uses MFA — TOTP, email OTP, push, WebAuthn / biometrics — that the scanner can't replay.
  • The login is an SSO / OIDC / SAML flow that bounces through an identity provider you don't want to script.
  • You can grab a working session in seconds (Levo browser extension, DevTools, a session-export extension) but encoding the login flow would take hours.
  • The app uses strict cookies (SameSite=Strict, __Host- prefix) where the AI / form-login flow can't reliably keep state.
  • One-off or exploratory scans where standing up a dedicated test account isn't worth it.
Sessions expire

Browser sessions are short-lived. If the session times out mid-scan, the scanner starts hitting the login wall and findings drop off. For recurring scans, prefer Username and password or AI-assisted login so each run gets a fresh session.

Input modes​

The dashboard accepts three ways to provide a session. Pick the one that matches how you captured it.

1. Session transplant (extension export)​

The richest format. A single JSON file exported by the Levo browser extension (or any extension that produces the same shape) — captures cookies with full attributes (domain, path, httpOnly, SameSite), plus localStorage and sessionStorage for every origin you visited while logged in.

This is the most reliable option for strict apps because it preserves cookie attributes the manual table can't (SameSite=Strict, __Host- prefix, exact Path, HttpOnly).

In Step 2 → Browser session, choose Session transplant and upload the exported .json file.

2. JSON upload / paste​

Paste a session-export JSON blob into the Session JSON field, or click Upload JSON to load it from a file. Use this when your tooling produces a custom JSON shape that's structurally similar to a session-transplant export but didn't come from the Levo extension — the dashboard normalizes common shapes (cookie arrays, header maps).

3. Manual entry (cookies + storage)​

Fill the values by hand when you grabbed them straight from DevTools. Useful when you only need a session cookie or two and don't want to install an extension.

SectionWhat goes in it
CookiesEach row is a Key / Value pair from the authenticated session — typically the session cookie (sessionid, JSESSIONID, connect.sid, …) plus any auth-related cookies the app sets after login. Use + Add Row to add more.
HeadersEach row is a Key / Value header to attach to every request — e.g., Authorization: Bearer …, X-Tenant-Id: …, custom auth headers your gateway expects.
Local StorageEach row is a Key / Value pair written to localStorage for the target origin. Required for SPAs that read auth tokens from localStorage instead of cookies.
Session StorageEach row is a Key / Value pair written to sessionStorage for the target origin. Same idea as Local Storage, but cleared when the tab closes.

Leave a section empty if your app doesn't need anything in it.

Capturing values from DevTools​

  1. Log into the target app in a normal browser tab.
  2. Open DevTools → Application (Chrome) or Storage (Firefox).
  3. Cookies → your origin — copy relevant names and values into the Cookies table.
  4. Local Storage → your origin — copy auth-related keys (e.g. access_token, auth.user) into Local Storage.
  5. Session Storage → your origin — copy any auth-related keys into Session Storage.
  6. If the app also relies on a custom header (visible under Network → any authenticated request → Request Headers), copy those into the Headers table.

CLI​

The CLI accepts the same session-transplant JSON via --auth-session-file:

shadownet scan https://app.example.com \
  --auth-session-file ./session.json

Or via env var (preferred in CI — the value is a path, not a secret):

export SHADOWNET_AUTH_SESSION_FILE=./session.json
shadownet scan https://app.example.com

The expected JSON is the export shape produced by the Levo browser extension — cookies with full attributes, plus localStorage and sessionStorage keyed by origin. When --auth-session-file is set, the scanner skips the auth phase entirely; you don't need --auth, --username, --password, or --login-url.

Why prefer this over `--auth form`?

For apps with strict cookies (SameSite=Strict, __Host- prefix) or any MFA-protected login, --auth-session-file is significantly more reliable than scripting the login. The trade-off is freshness — re-export the session whenever it expires.

YAML​

There is no auth.strategy: browser-session key. Provide the session file via env var (SHADOWNET_AUTH_SESSION_FILE) instead — the scanner picks it up regardless of the auth.strategy value in levo-dast.yml.

Pre-Auth fields still apply​

The shared Pre-Auth Cookies / Headers / Local Storage rows on Step 2 still apply to a Browser session scan. Use them for values the app needs before it accepts the session — tenant selectors, feature flags, gateway tokens — that aren't part of the authenticated session itself.

Next​

Was this page helpful?