Tested fixes for the weaknesses A07:2025 maps, in Express, Flask, Spring Boot, ASP.NET Core, Next.js, FastAPI, Django, net/http, Rails and Laravel: the vulnerable code, the fix, a wrong fix and the regression tests.
Weak authentication lets attackers take over accounts through credential stuffing, brute force, weak recovery or flawed session handling.
- Offer and encourage multi-factor authentication, and never ship default credentials.
- Check new passwords against breached-password lists and follow NIST SP 800-63B rather than forcing composition rules or periodic rotation.
- Limit or slow failed sign-in attempts, use the same message for every failure, and alert on credential stuffing.
- Issue a new random session identifier at sign-in, keep it out of URLs, and invalidate it at logout and timeout; validate tokens’ audience and issuer.
Guides on this site
Session management: cookies, timeouts, rotation and revocation
Model authentication as transitions in server authority, set session cookies and timeouts to current NIST and OWASP values, and verify fixation prevention, expiry, reauthentication, revocation and stolen-cookie defenses.
Passkeys and MFA: WebAuthn enrollment, sign-in and replacement
Register, verify and replace passkeys with WebAuthn so phishing resistance survives the account’s whole lifecycle, and map passkeys and other MFA methods to the NIST SP 800-63B-4 assurance levels.
Account recovery: password resets, help-desk resets and account linking
Treat password resets, support-desk recovery and account linking as new grants of authority: single-use high-entropy proofs, atomic consumption, session revocation, and stable identity rather than email matching.
OAuth 2.0 and OpenID Connect login: authorization code with PKCE
Implement OAuth 2.0 and OpenID Connect login with the authorization code flow and PKCE, keep each transaction bound to its browser, and block redirect, mix-up, code-injection and token-theft attacks.
JWT validation: algorithms, keys, claims and key rollover
Validate a JWT against a fixed algorithm, trusted keys and the expected issuer, audience and type, reject the known header attacks, and rotate signing keys without accepting arbitrary keys or breaking valid tokens.
SAML single sign-on: verify signed assertions without losing the identity boundary
Bind a validated SAML assertion to its trusted issuer, the exact signed element, your service, the browser request and a replay record before creating a local session, and keep your SAML library ahead of its advisories.
Defend JWTs against forgery, confusion and replay
Verify a JWT as an issuer-, type- and audience-bound assertion with an algorithm allowlist and trusted keys, closing the alg "none", key-confusion, header-injection, weak-secret and replay attacks.
Stop account takeover with the right MFA and login defenses
Rank MFA options by the attacks they stop, implement TOTP and push approvals correctly, and close the login, reset and recovery paths that attackers use instead of breaking the second factor.
Defend OAuth and OIDC against redirect and token attacks
Apply RFC 9700 and RFC 10017: exact redirect matching, PKCE with downgrade protection, state and iss binding, refresh-token rotation, sender-constrained tokens, and a backend-for-frontend so browser tokens cannot be stolen.
Password storage: hashing parameters and rehash on login
Choose Argon2id, scrypt, PBKDF2 or bcrypt with current minimum parameters, store a versioned hash, and upgrade old hashes after a successful login without overwriting a reset.
Operate TLS and certificates: configuration, renewal and verification
Configure a modern TLS profile with hybrid post-quantum key exchange, automate renewal for certificate lifetimes that fall to 47 days, and verify every termination point with a fresh handshake.
Maintain an API inventory and prevent gateway bypass
Connect documented routes, deployed listeners and backend trust so retired or direct paths do not bypass the intended controls.
Workload identity federation: short-lived, scoped identities for services and CI
Trace how a running workload obtains a short-lived identity, write cloud trust policies that match immutable claims instead of names or wildcards, and keep the resulting credential limited by audience and authorization.
SCIM deprovisioning: make account disablement remove every usable authority
Connect SCIM resource updates to current sessions, tokens, group-derived permissions and background jobs, with explicit tenant mapping, CAEP revocation events and a measurable revocation contract.
Verify webhook deliveries before acting
Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action.
Authenticate workloads and authorize their service actions
Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization.
Operate edge rules without hiding application defects
Tune WAF and abuse controls against legitimate traffic, parser behavior and measurable business effects.
Contain a leaked secret, then investigate and clean up
Revoke an exposed API key, token or private key at its issuer before anything else, end the sessions it minted, check the provider's logs, then remove every copy and replace it with a credential that expires on its own.
Practice
- JWT validation lab: Validate the purpose and audience of a token · Browser lab
- Password reset token lab: Make a recovery credential single-use · Browser lab
- Webhook signature and replay lab: Repair a webhook handler that pays twice · Browser lab
- JWT verification lab: Verify a JWT before trusting it · Browser lab
- OAuth redirect and PKCE lab: Match redirect URIs and verify PKCE · Browser lab
- Password hashing lab: Verify and upgrade an Argon2 password hash on login · Browser lab
- Secure a real HTTP API · Local project
- Repair a real proxy and shared cache · Local project
- Verify tokens through rotation and revocation · Local project
- Prove deprovisioning reaches sessions and queued work · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.