Authentication and sessions
These scanners all test how a server decides who you are and how many tries you get. Four of them send requests as a client that should be refused: with no session, with a forged token, or with a made-up identity. The fifth reads the page the crawler already captured. Each one turns a difference the server should not show into a finding: a reply that varies with the account, a credential that works without a valid signature, a counter that never trips.
How this group works
Three clients, three doors. Each step below is one scanner of the group sending its characteristic request, or in the last step reading what it already has. Watch which client sends it, what comes back, and which part of the reply is the finding.
1Three clients and three doors. Each scanner picks the client that should be refused and sends the request a legitimate user would send. The decision rests on what the reply reveals, or on how many requests it takes before the server pushes back.
2JWT. The scanner takes the real token from the login session, rebuilds it with alg: none, a weak secret or a swapped algorithm, and sends it to a protected endpoint. A 2xx that a garbage-token control did not also get means the server never checked the signature.
3Auth bypass. Two logins that differ only in the email. Different error phrases, a timing gap above 0.5 s or different status codes reveal which accounts exist. It deliberately carries no session: with one, its anonymous probes would not be anonymous.
4Password reset. Five reset requests in a row. If none is answered 429, an attacker can flood an inbox or grind through tokens. The same endpoint is also compared across two emails and searched for a token in the reply.
5Rate limit. The endpoint's own request repeated up to 150 times. Reaching the end without a 429 is HIGH. A 429 gives a measured threshold, and further bursts and an identity switch probe how the limit is keyed.
6Session. No request goes out. The scanner reads the HTML, scripts and cookies the crawler captured, and flags tokens in localStorage and auth cookies without HttpOnly or Secure.
Scanners in this group
JWT attacks
A forged token that the server accepts: alg none, weak secrets, RS to HS key confusion, plus the claims a token should carry.
Session
No request at all: it reads the captured snapshot for tokens in localStorage, auth cookies missing HttpOnly or Secure, and JWTs valid for more than 24 hours.
Auth bypass
Five phases with no session: username enumeration, 10 failed logins, seven default credential pairs, reset token leaks and Authorization header tricks.
Password reset
Email enumeration by status or length, five rapid requests with no 429, and a reset token returned in the reply.
Rate limit
The count to the first 429, bursts of 10, 50 and 100, and whether a new Authorization header resets the allowance.
At a glance
| Scanner | What it looks at | What it reports | Severity | Needs |
|---|---|---|---|---|
| JWT scanner | The session JWT, a protected endpoint, scripts for tokens in URLs | Forged tokens accepted (alg none, weak secret, key confusion); missing exp, iat, iss; a token in a URL | Info to Critical | URL; an authenticated session (forgery tests are skipped without a token) |
| Session scanner | The captured snapshot: JavaScript, response cookies, optionally the session JWT | A token in localStorage; auth cookies missing HttpOnly or Secure; a JWT valid more than 24 hours | Medium to High | URL only; runs at quick depth; sends no request |
| Auth bypass scanner | Login, reset and auth-required endpoints, matched by URL substring | Username enumeration, no lockout, default credentials, reset token in a reply, Authorization header bypass | Medium to Critical | URL; --depth deep; deliberately not auth-aware |
| Password reset scanner | Endpoints whose URL looks like forgot or reset password | Email enumeration, five unthrottled resets, a token in the reply body | Medium to Critical | URL; --depth deep; auth-aware when a session exists |
| Rate limit scanner | Endpoints with login, signup, password, reset, token or otp in the URL | No 429 in 150 requests; the measured threshold; mixed bursts; a limit that resets on a new identity | Info to High | URL; --depth deep; auth-aware except the identity test |
The session scanner runs in the default quick scan. The rate limit, auth bypass and password reset scanners are the three aggressive probes added by --depth deep. On an authenticated deep scan the crawl's session is handed to every HTTP scanner that exposes _auth_headers: rate limit and password reset take it, while auth bypass is skipped on purpose because its tests depend on the absence or forging of authentication.
Why this class matters
Authentication is the front door and the session is the key it hands out. A token in localStorage or a cookie without HttpOnly turns any XSS into account takeover. A JWT that is accepted without a valid signature lets anyone mint tokens for any user. Without lockout or rate limiting, guessing is free, and a reset flow that confirms which emails exist or returns its own token makes takeover a single request. Nothing here needs a clever payload: the server simply answers what it should have refused.
British Airways (2018). Injected JavaScript could reach client-side storage, enabling exfiltration of payment data and session tokens. iCloud (2014). No lockout or rate limit on the Find My iPhone API allowed brute-force attacks on celebrity accounts. Dunkin' Donuts (2015). Credential stuffing against an app with no rate limiting took over accounts and drained stored value. Snapchat (2014). The password reset flow allowed enumeration and confirmation of phone numbers linked to accounts. jsonwebtoken CVE-2015-9235. The library accepted alg: "none" by default, a complete authentication bypass for apps that did not restrict algorithms.