Authenticated Scanning

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

Three methods at a glance

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

Screenshot (TODO): Authentication tab in Scan Settings with method selector

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.

1. Open your app in a browser and sign in.
2. In DevTools → Application → Cookies, copy the session cookie name, value, and domain.
3. In TestKase Scan Settings → Authentication → Cookies, click Add cookie and paste each value.
4. 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 headless browser before visiting the first URL.

Method 2 — Login Form

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.

Screenshot (TODO): Login Form fields with username/password and selectors

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.

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.

1. Add one or more header name/value pairs.
2. 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.
• Report exports never include credential values.
• Re-scanning a scan reuses the saved auth config. Delete the scan to wipe its auth payload.

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.

See Troubleshooting for the full list.

Related

• Website Scanner
• Workflow Analyzer