In September 2022, an Australian telecom carrier left a legacy testing API reachable from the open internet with no authentication in front of it. Attackers found it, queried it directly, and walked away with personal records for 9.8 million Optus customers — names, birth dates, passport and driver's license numbers. No zero-day, no exploit chain, no malware. Just an API that was configured to trust any caller.
That is the essence of API security misconfiguration: not a flaw in the code, but a flaw in how the code was deployed, exposed, or left unattended. OWASP formalized it as API8:2023 in the current API Security Top 10, and it shows up in breach reports from Peloton to T-Mobile to the U.S. Postal Service. This post walks through what counts as a misconfiguration, why it keeps happening at scale, what real incidents reveal, what it costs, and how to catch it before an attacker does.
What Counts as an API Security Misconfiguration?
It's any gap between how an API was intended to be secured and how it is actually deployed — and OWASP's API8:2023 category groups roughly a dozen recurring patterns under that umbrella. The most common: missing or overly permissive CORS policies, verbose error messages that leak stack traces and internal hostnames, default credentials left active on management endpoints, unpatched TLS ciphers, unnecessary HTTP methods (PUT, DELETE, TRACE) left enabled, and — the Optus scenario — debug or staging endpoints promoted to production without authentication ever being bolted on.
None of these require a novel exploit. A misconfigured API often responds exactly as designed; it just wasn't designed to be public. Peloton's 2021 exposure is the clean example: an API endpoint returned full user profile data — age, gender, weight, city — to any authenticated Peloton account querying someone else's user ID, because the endpoint checked "are you logged in," not "should you see this specific user's data." Security researchers at Pen Test Partners reported it in January 2021; it took Peloton roughly three months to fully close it after initial partial fixes.
Why Are Misconfigured APIs So Common?
Because APIs multiply faster than the processes meant to govern them, and every new one starts from a config file, not a security review. The average enterprise now manages several thousand APIs across internal microservices, partner integrations, and public developer platforms, and Salt Security's State of API Security report has repeatedly found that a majority of organizations don't have a complete, current inventory of their own APIs. You cannot configure — or reconfigure — an endpoint you don't know exists.
Three structural pressures compound this. First, shadow and zombie APIs: a v1 endpoint gets replaced by v2, but v1 stays live because nobody owns decommissioning. Second, cloud-native defaults are permissive by design — API gateways, Kubernetes ingress controllers, and serverless triggers ship with broad default access so developers can move fast, and "harden before launch" is a step that gets skipped under deadline pressure. Third, configuration lives in dozens of places at once — the gateway, the load balancer, the application framework, the cloud provider's IAM policy, the WAF — and a correct setting in one layer can be silently overridden by a permissive default in another.
What Have Real-World Breaches Actually Looked Like?
They look like authentication that was never wired up, not authentication that was broken. T-Mobile disclosed in January 2023 that an attacker had used a single API, starting around November 25, 2022, to pull data on 37 million customer accounts — names, addresses, emails, phone numbers, dates of birth — before it was noticed, roughly six weeks later. It was T-Mobile's eighth publicly disclosed breach since 2018, and several of the prior ones traced back to API and access-control gaps as well.
The USPS "Informed Visibility" incident in 2018 is an earlier, similarly plain example: a public-facing API let any authenticated user query data belonging to any of the program's roughly 60 million users, because the API validated that a session existed but not what that session was allowed to request. Researcher Brian Krebs reported it in November 2018; USPS confirmed it had been exposed for over a year before a fix shipped.
The common thread across Optus, Peloton, T-Mobile, and USPS is that each API behaved exactly as configured. The configuration itself — not the application logic — was the vulnerability.
What Does a Misconfiguration Actually Cost?
More than the breach itself, once regulatory and remediation costs are counted. Optus faced an Australian government inquiry, a proposed class action seeking damages for millions of affected customers, and an eventual AU$1.5 billion-plus commitment toward remediation and customer support disclosed in the aftermath. T-Mobile agreed to a $350 million settlement in 2023 tied to a separate 2021 breach, and set aside further amounts for the 2023 API incident specifically, alongside a commitment to spend an additional $150 million on security infrastructure over the following two years.
Beyond headline settlements, IBM's Cost of a Data Breach research has consistently found that breaches involving compromised or unsecured APIs and web applications carry higher-than-average detection and containment costs, largely because misconfigurations tend to be silent — there's no crash, no alert, no failed login to trip a threshold. Salt Security's 2023 survey of security and API leaders found that 94% of respondents had experienced a security incident in production APIs in the prior 12 months, and roughly one in five had that incident escalate into an actual data breach. Misconfiguration is consistently cited as one of the top two or three root causes, alongside broken object-level authorization.
How Can Teams Detect Misconfigured APIs Before Attackers Do?
Mainly by treating API discovery as a continuous process rather than a one-time audit, since you cannot secure a configuration on an endpoint your inventory doesn't list. That means diffing live traffic against your documented API surface on an ongoing basis to surface shadow and zombie endpoints, not just scanning the specs your teams remembered to publish.
From there, four checks catch most of what shows up in breach post-mortems: verifying authentication is enforced at every endpoint and every environment (staging and internal APIs included, not just production-facing ones); confirming authorization checks scope data to the requesting identity rather than just verifying that some identity is logged in; scanning for verbose error handling that leaks internal paths, versions, or stack traces; and validating that gateway, WAF, and cloud IAM configurations agree with each other rather than assuming the strictest layer wins. Rate limiting and CORS policy review round these out — both are cheap to implement and both were absent or misapplied in the majority of the incidents referenced above.
None of this is exotic tooling; it's disciplined coverage applied continuously, because a config that was correct at last quarter's review can drift the moment a new gateway rule or IAM policy change ships.
How Safeguard Helps
Safeguard treats API configuration as a first-class part of the software supply chain, not a separate security silo bolted on after deployment. Our platform continuously discovers APIs across your environments — including shadow endpoints and forgotten staging instances — and maps them against what your teams believe is live, closing exactly the inventory gap that let Optus's testing API and T-Mobile's exposed endpoint go unnoticed.
For every discovered API, Safeguard evaluates authentication and authorization posture, flags overly permissive CORS and default-credential configurations, and checks for the verbose error handling and unnecessary method exposure that show up repeatedly in OWASP's API8:2023 guidance. Because configuration drift is continuous, checks run continuously too — a policy change in your API gateway or a new IAM role attached to a serverless function gets evaluated the same day it ships, not at the next quarterly audit.
Findings are prioritized by exploitability and blast radius rather than raw count, so security and platform teams can fix the handful of misconfigurations that would actually expose customer data first, and route the rest into normal remediation workflows. The result is the same outcome every one of the incidents above was missing: knowing what's exposed, how it's configured, and whether that configuration matches intent — before an attacker finds out first.