Audit the pages behind your login

Yes. Auth configuration is encrypted with AES-256-GCM before it is written, using a key held in the environment and never in the database. Each record gets its own random initialisation vector and an authentication tag. The decrypted form exists only in memory for the duration of a scan run, is never written back in the clear and is never logged. Reading a scan does not return your credentials: what comes back is cookie names and their domains, header names without their values, and for a form login the URL and the three selectors — never a cookie value, a header value or a password. You can rotate or delete a credential at any time.

Form login fills a username, a password and a submit button, so an account that challenges for a second factor cannot be driven that way, and a redirect out to an identity provider and back is not scripted. For MFA or SSO, capture the resulting post-authentication session as cookies or a header token and supply those instead.

Up to 10 protected URLs per scan, each fetched with the authenticated session so the audit reflects what a signed-in user sees. Authentication only gets the scanner to the page — it does not click anything. Everything past that is the same static scan, so states behind an interaction need a separate workflow audit.

For cookie- and header-based auth the scan fails cleanly with an auth error and you can paste a fresh value; for login-form auth TestKase re-walks the form at the start of each scan. Nothing refreshes a cookie you supplied, so a recurring scan on a short-lived session will quietly start scanning whatever the app shows a logged-out visitor. A clean result on an app you know has problems usually means it scanned your login page, the cookie domain did not match, the session expired, or the app was still rendering.

Findings are stored with the failing element and its DOM context, and a snapshot of the page is kept so the element inspector still works after the scan. On an authenticated page that snapshot can contain whatever the signed-in account sees, so point the scan at a test account rather than a real customer's. Form values you type and API response bodies are not captured, and everything is deleted with the scan or when the 90-day retention window closes.