Authenticated Scanning

Scan pages behind a login using cookies, an automated login form, or HTTP headers.

If the pages you want to scan require a sign-in, TestKase can authenticate the scan browser (a real desktop browser from the Device Farm) before loading your URLs. Three methods are supported — pick the one that matches how your app authenticates.

Three methods at a glance

Method	Use when	You provide
Cookies	Your auth is driven by a cookie you can copy from a logged-in session	Cookie name, value, and domain (one or more)
Login Form	Your app has a standard HTML login form	Login URL, username, password, CSS selectors for the form fields
HTTP Headers	Your app accepts a bearer token or API key in a request header	Header name and value (one or more)

Open Scan Settings → Authentication in the New Scan form to configure.

Method 1 — Cookies

Best for: apps where a session cookie is the entire auth story, and you can copy a valid cookie from your browser's DevTools.

Open your app in a browser and sign in.
In DevTools → Application → Cookies, copy the session cookie name, value, and domain.
In TestKase Scan Settings → Authentication → Cookies, click Add cookie and paste each value.
Add more cookies if your app needs several (e.g., access + refresh).

Required fields per cookie:

Cookie name — e.g., session_id, JSESSIONID.
Cookie value — the raw cookie value.
Domain — e.g., app.example.com. The scanner sets the cookie scoped to this domain before navigating.

The scanner injects these cookies into the scan browser before visiting the first URL, and the session persists across every URL in the scan.

Best for: apps with a plain HTML login form (username, password, submit button).

Required fields:

Login Page URL — the page with the form, e.g., https://app.example.com/login.
Username — the account username or email.
Password — the account password.
Username Selector — CSS selector for the username input. Default: #username.
Password Selector — CSS selector for the password input. Default: #password.
Submit Selector — CSS selector for the submit button. Default: #login-button.

The scanner navigates to the login URL, fills the fields, clicks the submit button, waits for navigation, then visits your scan URLs.

Tip: if your form inputs use name or type instead of id, use attribute selectors (e.g., input[name="email"]).

Tip: if the login URL redirects after success, it just works — the scanner follows the redirect. If your login is SPA-based and changes state without a URL change, switch to Cookies instead.

If your app needs a moment after sign-in before the session is usable — a redirect chain, a token exchange, a dashboard that bootstraps client-side — add waitAfterLogin to the login config. It is milliseconds, and the scanner sleeps that long after the login navigation settles, before visiting your scan URLs.

{
  "type": "login",
  "loginConfig": {
    "loginUrl": "https://app.example.com/login",
    "usernameSelector": "#username",
    "passwordSelector": "#password",
    "submitSelector": "#login-button",
    "username": "[email protected]",
    "password": "…",
    "waitAfterLogin": 3000
  }
}

There is no field for this in the Scan Settings form; set it through the API, or use the Page load delay setting instead, which waits on every URL rather than once after login.

⚠️ successUrl does nothing. The login config accepts a successUrl and it appears in the API schema, but the scanner never reads it — it does not wait for that URL, and it will not tell you the login failed if you never land there. Do not rely on it to verify a login. Confirm the login worked by looking at the scan's results: an unauthenticated shell shows up as a near-empty issue list.

Method 3 — HTTP Headers

Best for: API-token-authenticated apps, environments behind HTTP basic auth, or any case where a header on every request is enough.

Add one or more header name/value pairs.
The headers are sent on every request to every URL in the scan.

Common headers:

Authorization: Bearer eyJhbG... — JWT token.
X-API-Key: abc123 — API-key-protected endpoints.
Authorization: Basic dXNlcjpwYXNz — HTTP basic auth (base64 of username:password).

Security

All credentials (cookies, passwords, headers) are encrypted at rest.
They are loaded into the scanner only for the duration of the scan and are never echoed back in reports or exports. Opening a scan returns a stripped copy of the auth config: no cookie values, no password, no header values, and not even the username.
Report exports never include credential values.
Re-scanning a scan reuses the saved auth config. Delete the scan to wipe its auth payload.

What is visible. The stripped copy still carries enough for the UI to show that auth is configured, and anyone who can open the scan — including members of a team it is shared with — can see it:

Method	Returned to the report
Cookies	Each cookie's name and domain
Login Form	The Login Page URL and the three CSS selectors
HTTP Headers	The header names (e.g. `Authorization`)

None of that is a credential, but treat it as public to your accessibility teams: don't put a secret in a cookie name, a header name, or a login URL query string.

Troubleshooting

"Login failed" — the form selectors didn't match, or the credentials are wrong. Verify selectors in your browser's DevTools console.
"Page redirected to login" — the cookie/header/session expired, or the cookie domain doesn't match the URL being scanned.
Empty or near-empty issue list — the scanner may have been served an unauthenticated shell. Double-check the cookie value or try Login Form instead.
Login page never navigates — the scanner clicks the submit button and waits for a navigation. A login that swaps state without a page navigation times out the scan; use Cookies for those apps.

See Troubleshooting for the full list.

Authenticated Scanning

On this page