Webscan Documentation

Lesson 11 · Authenticated scanning

Phase 3 · Beyond the public page — Lesson 11 of 21 · All lessons

Objective: understand what "authenticated scanning" means, set up an authentication profile so webscan can sign in, and run a scan of pages that live behind a login.

Before you start: a website (Lesson 3) whose interesting pages require logging in — a dashboard, an account area, an admin panel.

Why this lesson exists

Everything so far scanned public pages — pages anyone can reach without signing in. But most real barriers hide behind the login: the account settings, the dashboard, the checkout. A normal scan can't see those, because it isn't logged in.

Authenticated scanning — scanning pages that require a signed-in session. "Authenticated" simply means "logged in." To do it, webscan needs a way to be logged in while it scans, and that's what an authentication profile provides.

Key terms

Authentication profile — a saved way for webscan to obtain a logged-in session for one website. You create it once and reuse it.
Session — the signed-in state a browser holds after you log in (usually a cookie or token). Webscan needs a valid session to see protected pages.
Test account — a dedicated, low-privilege account you create specifically for scanning, separate from any real person's account. Always use one of these, never a real user's or an admin's personal login.

When you create an authentication profile you'll choose an auth type:

1. Log in with a test account (recommended)

You give webscan the login page URL, a test account username/email, and its password. Webscan then signs in itself, headlessly, each time it scans — no terminal, no exporting anything. Fields you fill in:

Field	What it's for
Login page URL	The page with the sign-in form, e.g. `https://example.com/login`.
Test account username / email	The dedicated test account's identifier.
Test account password	Its password (stored encrypted; never shown again).
Field selectors (optional)	Only needed if webscan can't auto-find the username/password/submit fields — e.g. `#email`.

You enter these credentials yourself. Type your test account's details into the form — never a real user's password, and never share credentials in chat. Webscan encrypts them at rest and never displays the password again. Because it's a dedicated test account, even that is low-risk.

2. Import browser state (advanced)

If you'd rather not hand over credentials, you can paste a Playwright storage state — a JSON snapshot of an already-logged-in browser session. This is the developer path; use it only if you know how to export that JSON. Most people should use the test-account option above.

There's also a user-assisted style for cases where a human helps establish the session. The test-account path covers the vast majority of needs.

Set the expiry

Every profile has an expiry date (it defaults to about 30 days out). Sessions and passwords don't last forever, so webscan makes the profile's lifetime explicit.

Watch this one: an expired profile silently blocks authenticated scans — a common reason a scan unexpectedly comes back with only public pages. If that happens, check the profile's status (Active / Expired / Revoked) and refresh it.

Scan profiles: putting it to work

An authentication profile says how to log in. A scan profile says how to run a scan — and it's where you attach the authentication. Create a scan profile on the website's Scan profiles page with:

a name,
an optional user role label (e.g. "Standard user", "Admin") so you can tell scans of different permission levels apart,
the authentication profile to use,
a page limit, and
an active toggle.

Then run the profile to start an authenticated scan. Webscan logs in using the attached authentication profile and crawls the protected pages, producing findings exactly like a public scan — which then flow through verdicts, issues, and fixes just as you learned in Phase 2.

Tips & pitfalls

Point the login URL at the actual sign-in page, not the site root. If it points at the homepage, webscan may never reach the form and the scan falls back to public pages.
Always use a dedicated test account, ideally with the permission level you want to test (a "standard user" account finds different pages than an "admin" one).
If an authenticated scan returns only public pages, the usual causes are: the profile expired, the login URL is wrong, or the sign-in form's fields weren't found (set the optional selectors).
Name scan profiles by role. "Admin area" vs "Member area" makes your scan history instantly readable.

Recap

Authenticated scanning reaches pages behind a login using an authentication profile.
Prefer the test account type (webscan signs in itself with a dedicated account's credentials, encrypted); imported browser state is the advanced path.
Profiles expire — an expired one silently blocks authenticated scans.
A scan profile attaches the authentication and is what you run; its findings flow through the same Phase 2 workflow.

Try it yourself

Create a dedicated test account on your site. Add an authentication profile (test account type) pointing at the real login URL, then a scan profile that uses it, and run it. Confirm the scan now includes at least one page you can only see when logged in.

Previous: ← Lesson 10 · Retests & auto-verify Next: Lesson 12 · Agentic exploration →