Broken Authentication

This bucket sweeps a wide range of auth bypasses, missing-auth endpoints, and unverified-account abuses. Top patterns:

• admin/dashboard panels reachable without auth (Grafana, Prometheus, Kibana, Jenkins, Adminer, Spring Boot Actuator, Cisco ASA web interface) - 'no auth' rather than 'wrong auth'
• outdated software with auth-bypass CVE (Cisco ASA CVE-2020-3187, F5 BIG-IP, Citrix ADC, Atlassian)
• email-verification bypass - connect external login to unverified email allowing later takeover
• password reset / forgot password vulnerabilities - token reuse, weak token entropy, response leaking new password, no rate limit, predictable serial numbers
• JWT issues - alg=none, weak HS256 secret, kid SQLi, unverified workhorse JWT, missing audience/issuer checks
• Firebase/Realtime Database open globally
• closed-account-still-works - backend doesn't invalidate session/token after account closure
• state-changing actions on unauthenticated public APIs (TAMS pendingUserDetails, GraphQL service-only endpoints)
• brute-force-friendly endpoints (no rate limit on login, registration, OTP)
• MFA/2FA bypass - alternate route, downgrade to SMS, replay old session, missing check on a specific endpoint. Significant overlap with Improper Access Control - IAC tends to be 'authorized but wrong role', this is 'authentication missing or broken'.

• Public-facing admin panels for dev/monitoring tools (Grafana, Prometheus, Jenkins, Kibana, Airflow, Druid, Superset)
• Network appliances (Cisco ASA, F5, Citrix ADC) with known CVEs
• Spring Boot Actuator / Adminer / phpMyAdmin / Swagger UI exposing data
• Firebase / Mongo / Elasticsearch / Redis cloud-mounted instances
• JWT-based APIs with weak secret / alg=none
• Password-reset and OTP endpoints
• Multi-step auth flows (signup -> verify -> link)
• OAuth/SSO callback endpoints
• Mobile API mirrors of web auth flow

• Probe admin / monitoring / debug panels for unauth access (Grafana /api/dashboards, Jenkins /script, Spring Actuator /env)
• Match server banner against known-vulnerable network-product versions
• Attempt password reset for victim email; reuse token after expiry; truncate token; flip last char
• Decode JWT, switch alg to none, change subject claim, resubmit
• Brute-force JWT secret with john --jwt``
• Probe Firebase database URL (firebaseio.com/.json) for global read
• Connect attacker login service to victim's unverified account
• Replay session/cookie/token after account closure
• Brute-force registration / OTP / 2FA codes via numeric range
• Manipulate multi-step auth state (X-Auth-Step, hidden token in form)

• /api/dashboards (Grafana)
• /script (Jenkins)
• /actuator/env
• /manager/html (Tomcat)
• /+CSCOE+/logon.html (Cisco ASA)
• JWT with alg=none and no signature
• JWT with weak HS256 secret (try empty, 'secret', 'admin', kid SQLi)
• <firebase-db>.firebaseio.com/.json
• POST /forgot-password with empty token
• POST /reset-password with token=AAA padded with whitespace

Ensure templates for Cisco ASA CVE-2020-3187, F5 BIG-IP CVE-2020-5902, Citrix ADC CVE-2019-19781, Atlassian unauth CVEs, Firebase open-default.

Same wordlist as the IAC synthesis; specifically prioritize Grafana / Prometheus / Jenkins / Adminer / Spring Actuator.

For any URL ending in .firebaseio.com or any firebase config in JS, fetch /.json and check whether it returns data.

When an Authorization: Bearer header is observed on canonical traffic, decode the JWT, attempt alg=none, kid:'../', and weak-secret brute-force using a small HS256 dictionary; flag accepted variants.

Submit reset for a known email; if the response contains the new token / password, flag; verify the token is single-use and time-bounded.

For /login, /register, /forgot-password, /verify-otp, send a small burst (10 requests) with varying values and check whether the server returns the same 200 response without slowdown - flag low rate-limit.

Not testable by default, but document as an authenticated-scan capability - after account closure, replay last session and observe whether write operations still succeed.

Replay requests with X-User-ID, X-User-Email, X-Forwarded-User, X-Auth-User, X-Username, X-Original-User and check for status differential - many auth proxies trust these headers when forwarded from internal traffic.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Many admin panels intentionally expose login screens - the finding is when the panel is reachable AND grants access without credentials (or with default ones).
• JWT audit must require successful authentication after manipulation - reading the token alone isn't a finding.
• Rate-limit audit should respect ethical limits and never exceed 30 requests per minute per endpoint.
• Identity-proxy header bugs frequently appear behind cloud load balancers that strip these headers from external traffic - flag based on actual response differential, not just header presence.

Manual Testing Methodology

Here is a systematic approach to identifying Broken Authentication vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Broken Authentication specifically, walk every state transition in the login, MFA, and account-recovery flows out of order — call a later step directly, replay or predict a session/reset token, and submit a password/email change without the current credential — to see whether each step is independently enforced.

Compare the response against your baseline, looking specifically for a flow that completes despite an out-of-order or missing step, a predictable pattern across issued tokens, or a response that reveals account existence through a timing or content difference.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Broken Authentication, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Broken authentication covers weaknesses in the authentication mechanism itself, distinct from bypassing it outright: predictable or non-expiring session tokens, a password-change flow that doesn't verify the current password first, a "step" in a multi-step login that can be skipped, or account-recovery logic that leaks whether an email address is registered. Each of these individually looks minor; together they erode the assumption that "authenticated" means what the rest of the application thinks it means.

The practical consequence is usually targeted account takeover — an attacker who can predict a session token, skip a verification step, or abuse a weak recovery flow reaches the same outcome as someone who stole a password, without ever needing to steal one.

These flaws are disproportionately common in custom-built authentication relative to a well-vetted library or identity provider, precisely because authentication has a lot of edge cases (concurrent sessions, partial login states, recovery flows, remember-me tokens) that are easy to get subtly wrong once, and hard to notice are wrong without deliberately testing each state transition.

Prevention and Secure Coding

Preventing Broken Authentication takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Prefer a vetted authentication library or identity provider. Rolling custom authentication logic re-introduces edge cases that mature libraries and IdPs have already hardened against — reserve custom code for integration, not the core flow.

Verify the current credential before any change. Password and email changes should require re-entering the current password (or a fresh auth challenge), not just a valid session.

Treat every step of a multi-step flow as independently enforced. A later step in login, MFA, or recovery must re-verify that the earlier steps actually completed — never trust that the client only calls the endpoints in order.

Constant-response account recovery. Return the same response regardless of whether an email or username is registered, to avoid leaking account existence through timing or message differences.

Session tokens with real entropy, and real expiration. Generate session identifiers with a cryptographically secure random source, long enough to resist guessing, and expire them on a defined schedule and on logout.