Authenticated Scanning for Web Applications

How to configure authenticated scanning for each Web Application seed using Automated Authentication, Use Existing Token, or Manual Login Flow.

Overview

Most of a web application's attack surface lives behind the login page. An unauthenticated scan only sees what an anonymous visitor sees — the sign-in screen, marketing pages, and public endpoints. To test the authenticated application — dashboards, account settings, admin panels, and the APIs that power them — the Praetorian Guard Platform (PGP) needs to log in the way a real user would.

Authenticated scanning is configured per Web Application seed. Each seed can hold one or more credentials, and one credential is marked as the Default that scans use. This lets you scan the same application as different roles (for example, a standard user and an administrator) by adding a credential for each.

Guard offers three methods for supplying authentication to a Web Application seed. This article walks through what each one does, when to use it, and the fields you'll fill in — plus what to set up first.

Before You Begin

Set this up before you configure a credential.

Provision a dedicated scanning account

Do not point Guard at a real user's live credentials. Instead, provision a dedicated test account in the target application with the level of access you want scanned. This keeps a live user's session from being disrupted, gives you a clean audit trail, and lets you scope exactly what the scanner can reach.

When you create the account, capture everything the login flow will ask for: username, password, the account email, any security-question answers, and — if MFA is enabled — the TOTP (authenticator) secret. You'll enter these when you configure the credential.

Important: Some applications allow only one active session per account and will invalidate an existing session when a new login occurs. If multiple scans (or a person and a scan) use the same account at the same time, they can log each other out. Use a dedicated account per seed, and where possible avoid overlapping scan activity on the same account.

Where to Configure a Credential

Go to Assets and open the Web Application asset (or add it first from the Seeds page).
On the asset, open the Manage menu and choose Credentials (the key icon). Credentials are available on Web Application assets.
Click Add Credential. On Step 1: Select Authentication Method, choose one of the three methods below and click Next.
Fill in Step 2 for the method you chose and save.

A seed can hold more than one credential. Set the one you want scans to use as the Default from the credential's row menu (Set as Default) — the Default credential is the one scans authenticate with. Add a separate credential per role (e.g. standard user and admin) to scan the application from each perspective.

The Three Methods

Method	What it does	Best for
Automated Authentication	You supply a username and password (plus any other inputs). Guard's AI signs in for you and records the authenticated session so every scan runs fully logged in.	Standard username/password logins — including multi-field forms and MFA. Start here.
Use Existing Token	You already have a valid token, API key, or cookie. Paste your auth headers and Guard reuses them on every request.	API keys and anywhere you have a long-lived secret — a durable token or cookie you can supply directly.
Manual Login Flow	You define the login request yourself — a single request (typically a POST) and a rule for what to extract from the response.	Simple, easily automated logins where you already know the exact login request and where the session comes back.

Method 1 — Automated Authentication (recommended)

Provide a username and password and Guard's AI signs in for you, recording the authenticated session so every scan runs fully logged in. This is the method to try first. You give Guard the login URL and the secrets the login needs; a recorder agent drives a real browser through the sign-in, captures the authenticated session, and — on success — verifies the flow by deterministic replay and saves it automatically. Every subsequent scan reuses that logged-in session.

Fields:

Label — a name for this credential (for example, acme-prod-admin).
Login URL — the page where the login form lives (for example, https://app.example.com/login).
Recorder hint (optional) — free-text guidance for the agent when the page has more than one login path, such as "Use the Okta SSO button, not the username/password form."
Login Inputs — any key/value pair the login flow needs. Start with username and password, then click Add Input for anything else the form asks for — email, a security-question answer, an OTP backup code, and so on. There's no fixed limit on the number of inputs; add as many as the login requires.
TOTP secret (if MFA is enabled) — paste the authenticator secret or upload its QR code so Guard can generate one-time codes during login.

When you submit, the recorder runs live and you watch each step appear as it drives the browser. If it succeeds, the recipe is saved for you.

Multi-field logins are supported: for an application that asks for a username, password, email, and one or more security questions, add an input for each field the form presents, then submit — Guard handles the multi-step form and captures the session. Add however many inputs the flow needs.

Note: The agent only ever sees the keys (username, password, and so on). The values are substituted at call time and never appear in the recorded recipe or the conversation log.

Method 2 — Use Existing Token

If you already have a valid authentication artifact — a bearer token, an API key, or a session cookie — this is the fastest path. It's the right choice for API keys and anywhere you have a long-lived secret: paste your auth headers once and Guard reuses them on every request during the scan.

Fields:

Label — a name for this credential.
Headers — one or more key / value pairs. Common examples:
- Authorization : Bearer eyJhbGciOi...
- X-API-Key : <your API key>
- Cookie : session=<your session cookie>

Note: This method is ideal for API keys and other long-lived secrets. Short-lived session tokens and cookies expire — when the value you pasted is no longer valid, scans will run unauthenticated until you update the credential. If your secret is short-lived, prefer Automated Authentication so Guard can re-establish the session itself.

For simple, easily automated logins where you already know exactly how the login works, you can define the request yourself instead of letting the recorder discover it. The wizard has you make a single login request (typically a POST) and then extract the session from the response — so it's best when the login is one clean request/response exchange. A five-step wizard walks you through it:

Overview — give the credential a Label.
Login Credentials — the key/value inputs the login needs (username, password, and so on).
Login Request — the HTTP request that performs the login: URL, method (POST/GET), Content-Type, any extra headers, and the request body (Guard prefills a template using your inputs, e.g. username={{username}}&password={{password}}).
Capture Session — tell Guard where the session lives so it can be replayed on every request. Choose one:
- A cookie (most common) — the app returns Set-Cookie: session=… and the browser sends it back on each request.
- A response header — the session value comes back in a header (e.g. Authorization), which Guard replays exactly.
- A JSON token in the response body — the login returns JSON such as {"token":"…"}; Guard extracts it via a JSON path and places it into a header on every scan request.
Review & Save — confirm the assembled recipe and save.

Best Practices & Troubleshooting

Make sure the scanner can reach the app. If a WAF, Cloudflare, or IP/geo filtering is blocking or challenging the scan, work with your Praetorian team on how the scan reaches your target. Depending on your tenant's scanning settings, the agent may run from a static or a dynamic IP — not every tenant scans from a fixed address — so IP allowlisting isn't always the right lever. Where it applies, you can allowlist Guard's scan range (66.45.78.0/24); otherwise use the tenant Scan Header at the target's edge and disable bot/geo challenges for it. Most "can't reach the login page" issues trace back to this.
One dedicated account per seed to avoid session bleed and keep a clean audit trail.
Prefer TOTP over SMS/push MFA. Guard can generate TOTP codes from a secret; it cannot receive SMS codes or approve push prompts on its own.
Unsupported login flow? You can walk the agent through it. For authentication flows Guard can't automate on its own — SMS-based MFA, for example — ask Marcus (the in-platform AI assistant) to start a Romulus human-in-the-loop session. You provide the login and guide the agent through sign-in yourself for a one-time authenticated session.
If Automated Authentication fails, read the recorder timeline to see which step broke, then add a Recorder hint to steer it (e.g. which button to click). If the login is a single, well-understood request, Manual Login Flow lets you define it directly. If the flow genuinely can't be automated, use the human-in-the-loop option above.
Confirm it worked. After saving, set the credential as Default and run a scan; verify that findings and crawled paths reflect authenticated areas of the application, not just the login page.