Accessibility/Authenticated Scanning

Authenticated Scanning · Accessibility

Audit the pages behind your login

Most accessibility tools stop at public URLs. TestKase scans authenticated pages using your choice of cookie, login-form, or custom header authentication — so dashboards, settings, and admin panels finally get audited.

Start free View all features

Authenticated scan setup

Auth method

Header

Session cookies

session=eyJhbGciOiJIUzI1NiIs…csrf=Tx9v4QmA9fN2…

Protected URLs

/dashboard/settings/team/admin/billing

Credentials encrypted at rest · used once per scan

How it works

Three authentication methods. Zero compromises.

Pick whichever mechanism mirrors the way a real user reaches the page — cookies, forms, or headers.

STEP 1

Cookie-based

Paste your session cookies directly. TestKase replays them with each request — ideal for stateful session auth.

STEP 2

Login-form

Provide the login URL, input selectors, and credentials. TestKase submits the form, captures the session, and proceeds to audit.

STEP 3

Header-based

Inject Authorization headers, API keys, or custom tokens. Perfect for SSO, OAuth bearer flows, and machine auth.

Capabilities

The pages your public scanner can't reach

Audit the product where your real users live — not just the marketing site.

User dashboards

Home screens, onboarding flows, and in-product settings finally get tested.

Admin panels

Org-wide admin, billing, and role management — the highest-liability surfaces.

Account settings

Profile, preferences, security pages — where power users spend their time.

Multi-tenant surfaces

Workspace-scoped pages that only resolve with a valid session token.

Gated reports

Analytics dashboards, exports, and per-account reports behind role-based gates.

Internal tools

Employee-only dashboards and internal tooling that still need to meet WCAG.

Security posture

Your credentials, handled carefully

TestKase is built for production apps where the credentials matter. We store the minimum required, encrypt at rest, and scope every value to the scan that requested it.

Encrypted at rest

Every credential stored in TestKase is encrypted with per-tenant keys. No plaintext cookies or passwords in the database.

Scoped to one scan

Credentials are only pulled by the scan that needs them, held in memory for the crawl, and discarded after. Never logged.

Rotate anytime

Change or delete a credential and every downstream scan picks up the new value on the next run. No background re-use.

Config examples

Minimal config, maximum coverage

Each auth method takes a handful of fields. Paste once, reuse across every scan in the workspace.

Cookie-based

session:"eyJhbGciOiJIUzI1NiIs..."

csrf_token:"Tx9v4QmA9fN2..."

auth_domain:"app.example.com"

Paste cookies from a signed-in browser. Ideal for stateful session auth (Rails, Laravel, Django, Express + express-session).

login_url:"https://app.example.com/login"

email_selector:"input[name=email]"

password_selector:"input[name=password]"

submit_selector:"button[type=submit]"

Provide the form URL, selectors, and credentials. TestKase submits the form, catches the session, and proceeds to scan.

Header-based

Authorization:"Bearer eyJhbGciOiJSUz..."

X-Api-Key:"sk_live_4Fj2..."

Inject Authorization headers or API keys. Works with OAuth bearer flows, API-key auth, and SSO token-exchange patterns.

Enterprise ready

Plays well with SSO and identity providers

Your real users log in through Okta, Auth0, or Azure AD — and so can TestKase. Use header-based auth for post-SSO sessions or let the form walker handle the provider's UI.

Okta

Auth0

Azure AD

Google SSO

AWS Cognito

OneLogin

Keycloak

SAML 2.0

OAuth 2.0

OIDC

JWT bearer

Session cookies

FAQ

Authenticated Scanning FAQ

Use cookie-based auth if you already have a signed-in browser session you can copy from. Use login-form if you want TestKase to re-authenticate on demand. Use header-based for SSO/API/bearer-token flows where a form walk is not possible.