Missing Authentication

This is CWE-306, one layer more fundamental than missing authorization: here, a sensitive function requires no login at all, not even the wrong level of one. Missing authorization assumes a user has already authenticated and just checks the wrong thing (or nothing) about their role; missing authentication for a critical function means the function is reachable by a completely anonymous request, no session, no token, no credential of any kind. It shows up most often on internal tools and admin interfaces that were built assuming network-level isolation would keep them safe, then ended up reachable from the public internet anyway, with no authentication layer added as a second line of defense.

• Internal admin panels, monitoring dashboards, and management consoles reachable from the public internet
• Debug, health-check, or diagnostic endpoints that were never meant to be exposed but require no credential to access
• API endpoints intended only for internal service-to-service calls, with no authentication applied because the assumption was that only trusted internal callers could reach them

• Request a discovered endpoint with absolutely no authentication material present at all (no cookie, no Authorization header, no API key) and check whether it returns real, sensitive data or performs a real action rather than redirecting to a login page or returning a 401
• Look specifically at admin panels, internal tools, and management interfaces discovered during crawling or subdomain enumeration, since these are disproportionately likely to have been built with an assumption of network isolation that no longer holds once they're internet-reachable

• No injected payload; the test is a completely bare request with no credential of any kind

For every discovered endpoint, particularly ones that look administrative or internal based on their path or subdomain, send a request with zero authentication material and check whether it returns substantive data or performs a real action. This is one of the more reliably detectable classes on this list precisely because the test is binary: either the function requires some form of credential, or it doesn't.

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.

Confirm the endpoint actually exposes something sensitive or performs a real action before treating an unauthenticated 200 as a finding; a genuinely public status page or health-check endpoint returning a 200 with no credential is expected behavior, not a missing-authentication bug.

Manual Testing Methodology

Here is a systematic approach to identifying Missing 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 Missing Authentication specifically, request every protected endpoint directly without a valid session, with an expired or malformed token, and through any alternate interface (mobile API, legacy route, internal subdomain) the primary web login might not share code with.

Compare the response against your baseline, looking specifically for a successful response or authenticated-looking content returned where a 401/redirect-to-login was expected — check the actual response body and account state, not just the status code, since some bypasses return a nominal error page while still performing the requested action.

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 Missing 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

Authentication bypass vulnerabilities let an attacker reach authenticated functionality without valid credentials, by exploiting an alternate code path, a logic flaw in the login flow, or an endpoint that simply never enforces the check the primary login page does. The impact is effectively full account or system access, since it defeats the control everything else is typically built on top of.

These bypasses are especially common at the seams between systems: a mobile app's API backend that skips a check the web frontend enforces, a legacy endpoint kept alive after a rewrite, or an internal admin panel assumed to be unreachable from outside and therefore never gated.

Because authentication is the first gate in most security models, a bypass here tends to invalidate assumptions made everywhere else in the application — authorization checks built on "the user is authenticated" stop meaning anything once that premise no longer holds.

Prevention and Secure Coding

Preventing Missing 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.

Enforce authentication server-side, on every protected route. Never rely on a client-side route guard, hidden navigation, or "the frontend doesn't link there" as the actual control — assume every endpoint will be requested directly.

Centralize the check. Route protected traffic through shared authentication middleware rather than adding a per-controller check that's easy to forget on a new endpoint.

Audit every alternate access path for parity. API endpoints, mobile backends, legacy routes, and internal admin tools need the same enforcement as the primary login flow — inventory all of them explicitly rather than assuming they inherited the same protection.

Fail closed. If the authentication check itself errors or times out, the default behavior should deny access, not silently allow the request through.