In November 2022, an attacker found a single T-Mobile API endpoint that didn't require authentication. For roughly six weeks, they queried it undetected, pulling name, billing address, email, phone number, date of birth, and account PIN data for 37 million customers before T-Mobile noticed on January 5, 2023. A few months earlier, Optus in Australia lost records for 9.8 million customers — nearly 40% of the country's population — because a test API endpoint was left internet-facing with no authentication check at all. Neither breach involved a zero-day exploit, a phishing email, or stolen credentials. Both came down to the same root cause: an API endpoint that let requests through without properly verifying who was making them. Broken authentication in API endpoints is now one of the most consistently exploited weaknesses in production software, and it's the second-ranked risk in the OWASP API Security Top 10. Here's what it actually looks like, why it keeps happening, and how to catch it before attackers do.
What Is Broken Authentication in API Endpoints?
Broken authentication happens when an API fails to correctly verify the identity of whoever is calling it, letting attackers impersonate legitimate users or bypass login checks entirely. OWASP formalized this as API2:2023 in its API Security Top 10, describing it as authentication mechanisms that are "often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently." In practice this covers a wide range of specific failures: endpoints that skip authentication checks on certain routes (as in the Optus and T-Mobile cases), APIs that accept expired or forged JSON Web Tokens, password reset and account recovery flows without rate limiting, hardcoded or weak API keys shipped in mobile app binaries, and credential stuffing attacks that succeed because there's no lockout after repeated failed attempts. The common thread is that the API trusts a request it shouldn't.
Why Does Broken Authentication Keep Showing Up in Breaches?
It keeps showing up because APIs multiply faster than the authentication review process around them, and every new endpoint is a new opportunity to get it wrong. Salt Security's State of API Security report found that 94% of organizations surveyed experienced a security problem in their production APIs in the prior 12 months, and API attack traffic grew 400% over a six-month window as attackers automated discovery of exposed endpoints. Gartner predicted back in 2021 that APIs would become the most frequent attack vector by 2025, and the intervening years have borne that out. Modern applications expose dozens or hundreds of internal API routes to support mobile apps, partner integrations, and internal microservices — each one theoretically requiring its own authentication check, and each one a candidate for a developer forgetting to add it, copying an insecure pattern from another endpoint, or assuming an API gateway handles auth when it doesn't.
What Do Real-World Incidents Actually Look Like?
Real-world incidents range from missing checks on internal endpoints to fundamentally flawed token validation, and the pattern repeats across industries. Peloton disclosed in January 2021, after researchers at Pen Test Partners reported it, that its API let any authenticated user query private profile data — including age, gender, weight, and location — for any other Peloton account, including ones marked private, because the endpoint didn't verify that the requester should have access to that specific user's data. The U.S. Postal Service left an "Informed Visibility" API exposed for over a year until KrebsOnSecurity reported it in November 2018, allowing anyone logged into USPS.com to query account details for the site's roughly 60 million registered users simply by manipulating a request parameter, with no additional authentication required. On the token side, CVE-2022-23529 in the widely used jsonwebtoken npm library allowed remote code execution when an attacker controlled the secret or public key input, and the long-running "alg:none" class of JWT vulnerabilities lets attackers strip the signature algorithm entirely and get a forged token accepted as valid if the verifying code doesn't explicitly reject unsigned tokens. Each of these is a different technical mechanism, but each one is broken authentication.
How Do Attackers Find and Exploit These Endpoints?
Attackers find them the same way defenders should be looking: by systematically enumerating API endpoints and testing what happens when authentication is missing, weak, or bypassable. Common techniques include crawling mobile app binaries and JavaScript bundles for hardcoded API paths and keys, fuzzing predictable URL patterns (/api/v1/users/{id} with sequential IDs is a classic), replaying or manipulating JWTs to see if signature verification is actually enforced, and running credential stuffing campaigns against login and password-reset endpoints using breached credential lists — a technique that succeeds precisely because many APIs don't rate-limit authentication attempts the way web login forms do. Shadow and zombie APIs make this worse: old API versions, staging endpoints, and internal-only routes that were never meant to be public frequently stay reachable long after anyone remembers they exist, which is exactly the category the Optus test endpoint fell into. Once an attacker finds one working unauthenticated or under-authenticated endpoint, they don't need to compromise a single user account — they can often enumerate the entire dataset behind it.
How Can Teams Catch Broken Authentication Before Attackers Do?
Teams catch it by treating every API endpoint as untrusted by default and verifying that authentication and authorization checks are actually present and correctly implemented on each one, rather than assuming a gateway or framework handles it globally. That means maintaining a current inventory of every API endpoint — including internal, staging, and deprecated ones — since you can't secure what you don't know exists. It means enforcing consistent authentication middleware at the framework level instead of per-route checks that are easy to skip, validating JWT signatures and expiration server-side on every request rather than trusting client-supplied claims, and rate-limiting or adding progressive delays on login, token refresh, and password-reset endpoints to blunt credential stuffing. It also means testing authentication logic in CI, not just at code review: automated scans that specifically probe for endpoints reachable without valid tokens, and dependency checks that flag known-vulnerable auth libraries like the jsonwebtoken versions affected by CVE-2022-23529, catch issues before they reach production rather than after a researcher or attacker finds them first.
How Safeguard Helps
Safeguard approaches broken authentication as a software supply chain problem as much as an application-layer one, because the components and pipelines that produce your APIs are where these gaps get introduced and where they can be caught earliest. Safeguard continuously scans your codebase and dependency tree for known-vulnerable authentication libraries — including CVEs like the jsonwebtoken flaws referenced above — and flags them before they ship, rather than after they're deployed to a production endpoint. Because Safeguard tracks the full provenance of what's built and deployed, it can help teams maintain the endpoint and dependency inventory that's foundational to catching shadow and zombie APIs, the same class of forgotten, under-authenticated routes behind incidents like the Optus breach. Safeguard's build and pipeline attestation capabilities also make it possible to verify that authentication middleware and security controls present in source code actually make it unmodified into the deployed artifact, closing the gap between what engineers reviewed and what's actually running. For security and DevSecOps teams, that means fewer surprises: authentication weaknesses get surfaced as part of the software supply chain that produces every API, not discovered after 37 million records are already gone.