The API Security Crisis: Exposed Keys, BOLA, and the Invisible Attack Surface

In 2023, a single misconfigured API endpoint handed attackers the personal data of 37 million T-Mobile customers. No malware. No zero-day exploit. Just an API that failed to check whether the caller was authorized to see what it returned. That breach cost T-Mobile over $350 million in settlements. And it is far from an isolated incident.

APIs — the connective tissue of the modern internet — have quietly become the dominant attack surface in enterprise security. According to Akamai, API traffic now accounts for more than 83% of all internet traffic. Gartner predicted that by 2025, APIs would be the most frequent attack vector for web applications. That prediction has proven accurate. The question security teams face is no longer whether their APIs will be targeted, but whether they will notice when they are.

The OWASP API Security Top 10: A Map of the Crisis

The OWASP API Security Top 10 is the definitive threat taxonomy for the API era. Updated in 2023, it identifies the most critical vulnerabilities developers and security teams must understand. Two entries dominate the real-world breach landscape: Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA).

BOLA — ranked number one on the OWASP list — is deceptively simple. When an API endpoint accepts an object identifier (a user ID, account number, or order reference) and returns data without verifying that the requesting user is actually entitled to that data, BOLA exists. Attackers exploit it by manipulating identifiers: change `/api/orders/10042` to `/api/orders/10043` and, if BOLA is present, you receive someone else’s order details. Scale that across millions of records and you have a breach.

The 2022 Optus breach in Australia exposed the personal data of approximately 10 million customers through precisely this vector. An unauthenticated API endpoint incremented customer identifiers predictably, allowing a single attacker to enumerate records in bulk. Optus’s regulatory fine ran into tens of millions of Australian dollars. The technical root cause: one API endpoint, no object-level authorization check.

BFLA operates at the function level rather than the object level. An API might correctly restrict regular users from accessing `/api/admin/delete-user` via the user interface, yet expose the same endpoint without authorization controls at the API layer. Attackers who discover the endpoint — often through JavaScript source analysis or mobile app traffic interception — can invoke privileged functions regardless of their account tier.

Other significant OWASP entries include Broken Authentication (weak token validation, missing expiration), Excessive Data Exposure (APIs returning full objects when only a subset of fields is needed), Lack of Rate Limiting (enabling credential stuffing and enumeration attacks), and Security Misconfiguration (verbose error messages exposing stack traces, CORS misconfigured to allow any origin).

The Exposed Keys Epidemic

While authorization flaws require active exploitation by a skilled attacker, exposed API keys represent a different category of threat: passive, persistent, and extraordinarily common.

GitGuardian’s annual State of Secrets Sprawl report has documented the scale of this problem with precision. In 2024, GitGuardian detected over 12.8 million secrets exposed in public GitHub repositories — a figure that includes API keys, OAuth tokens, database credentials, and cloud provider keys. The detection rate has increased year-over-year. The root cause is structural: developers, under deadline pressure, hardcode credentials into source files, push those files to version control, and occasionally push that version control to public repositories. Even when the files are later deleted, the credentials persist in git history.

The consequences of a single exposed key can be catastrophic. When a developer at a major fintech accidentally committed an AWS root access key to a public repository, attackers with automated scanning tools detected it within four minutes. By the time the breach was identified and the key rotated, the attackers had provisioned hundreds of GPU instances for cryptocurrency mining, generating a cloud bill exceeding $80,000 in 48 hours. The credential itself was never used to access customer data in that incident — but the key could equally have opened S3 buckets containing millions of sensitive records.

The 2022 Twitter/X breach that exposed the data of over 5.4 million accounts originated from an API vulnerability disclosed through their bug bounty program in January 2022. The flaw allowed any attacker who knew a user’s phone number or email address to query the API and retrieve the associated Twitter account, including private account information. The vulnerability existed for months before Twitter was made aware of it. The data was subsequently sold on hacking forums.

Shadow APIs: The Attack Surface Nobody Maps

Beyond known vulnerabilities in documented APIs lies a darker problem: shadow APIs. These are endpoints that exist in production but are not tracked in any API inventory — forgotten legacy endpoints from deprecated product versions, internal endpoints inadvertently exposed to the internet, or third-party integrations where the API contract was never formally documented.

Salt Security’s 2024 State of API Security Report found that 78% of organizations experienced an API security incident in the previous twelve months. More significantly, 43% said they had no API inventory — they did not know what APIs they were running. You cannot protect what you cannot enumerate.

Shadow APIs are particularly dangerous because they often predate modern security controls. An API endpoint built in 2017 for a mobile app that was sunset in 2019 may still be reachable, may still be authenticated against an old credential store, and may still return data that is now subject to GDPR or other data protection regulations.

Tools Built for the API Era

The inadequacy of traditional WAFs and perimeter security for API-specific threats has given rise to a dedicated API security tooling market. Three vendors have established dominant positions.

Salt Security uses behavioral AI to baseline normal API traffic patterns and detect anomalies — particularly the slow, enumeration-style attacks that characterize BOLA exploitation. Rather than relying on signature-based rules, Salt learns what legitimate API consumption looks like and flags deviations.

Noname Security (acquired by Akamai in 2024) focuses on API discovery and posture management — automatically cataloging all API endpoints across an organization’s infrastructure, identifying those with known vulnerability patterns, and prioritizing remediation. Their platform integrates with API gateways, load balancers, and cloud environments to build the inventory that security teams lack.

Akamai API Security (incorporating the Noname acquisition) extends API protection to the edge, intercepting and analyzing traffic before it reaches origin infrastructure. For organizations already using Akamai for CDN and DDoS protection, API security capabilities are increasingly native to the platform.

Defending the API Surface: Best Practices

Effective API security is not a product purchase — it is an engineering discipline. The baseline controls every API must implement include strict object-level authorization checks at the data layer (not just at the route layer), OAuth 2.0 with properly scoped tokens and short expiration windows, and API gateways that enforce rate limiting, authentication, and request validation centrally.

Secrets management is non-negotiable. Tools like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault provide dynamic credential injection that eliminates the need for hardcoded secrets in source code. Pre-commit hooks using tools like git-secrets or TruffleHog can scan for credential patterns before code reaches version control.

API inventory is foundational. Organizations that do not know what APIs they are running cannot protect them. API discovery — whether through traffic analysis tools or code scanning — must be a continuous process, not a one-time audit. Every API endpoint should have a documented owner, a defined lifecycle, and a sunset date.

Finally, security testing must move left. OWASP’s API Security Testing Guide provides test cases for every Top 10 category. Integrating API security tests into CI/CD pipelines — testing for BOLA conditions, checking for excessive data exposure, validating rate limiting — catches vulnerabilities before they reach production rather than after they are exploited.

The invisible attack surface is only invisible to those who are not looking for it. In 2026, that excuse is no longer available.

Sources & Further Reading

• OWASP API Security Top 10 2023 — OWASP Foundation
• State of Secrets Sprawl 2024 — GitGuardian
• State of API Security Report 2024 — Salt Security
• Akamai API Security: Protecting the Modern Attack Surface — Akamai
• Optus Data Breach Investigation — Australian Communications and Media Authority
• T-Mobile API Breach Settlement — Reuters