This week, we look at a sharp rise in API security incidents across Asia-Pacific, and a critical API vulnerability in the dating app Raw. We also explore two credential-related incidents: one involving leaked OAuth credentials, and another highlighting the risks from long-lived API keys. Finally, a deep dive into the growing problem of API sprawl and the need for effective API governance to manage the numbers of APIs under development.
Industry Report: High numbers of API security incidents in APAC
A new survey report on the costs of API attacks in the Asia-Pacific region revealed an average cost of US$580,000 per incident over the past year. Australia reported the highest frequency of incidents, with 96% of organizations affected, while China estimated the highest average cost at US$780,000.
The report also mentions that many causes of these API incidents could be identified by developers before the APIs are released. However, the report goes on to place more emphasis on production testing than developer testing, which I find odd because in production, vulnerabilities are already exposed, and the complexity of diagnosing and resolving issues related to production traffic is much higher for developers.
The survey results indicate the top four likely causes of API security incidents as:
- API misconfigurations (22.3%)
- The network firewall didn’t catch it (20.8%)
- API gateway didn’t catch it (20.7%)
- Authorization vulnerabilities (20.6%)
API misconfiguration is a relatively broad category of API vulnerability. For example, among the various ways an API can be vulnerable to security misconfiguration, OWASP casts a wide net:
“Appropriate security hardening is missing across any part of the API stack”.
So, an API misconfiguration vulnerability (OWASP API8:2023) could be considered the root cause of other vulnerabilities, such as broken authentication (OWASP API2:2023), broken authorization (OWASP API1:2023), or excessive data exposure (OWASP API3:2023), depending on whether the vulnerability is categorized by root cause or impact.
It’s an interesting survey, though perhaps lacks clarity on some key points.
Vulnerability: Critical API security flaw in dating app ‘Raw’
TechCrunch researchers have revealed a security vulnerability in the dating app Raw, exposing users’ personal information and real-time location data. The flaw, an Insecure Direct Object Reference (IDOR), allowed unauthorized access to sensitive user details such as display names, birth dates, sexual preferences, and GPS coordinates accurate down to the street level.
We previously reported a similar issue in FeelD, another dating app, in issue 255 of APISecurity.io. These kinds of vulnerabilities are especially prevalent in applications designed for social networking, collaboration, or resource sharing, where APIs provide essential functionality to search for other members or for shared resources.
These APIs must be carefully designed to enforce proper authorization and ensure that the data returned is filtered based on the requester’s permissions and context. For example, an API that fetches the current users own profile data will be different to an API that fetches other users profile data. Attempting to mix the two can further complicate the access control mechanism.
Testing for authorization flaws in these scenarios is often complex. It typically requires simulating multiple user roles and permissions to fully assess authorization controls. However, this level of testing is essential for avoiding the top security risk in the OWASP API Security Top 10: Broken Object Level Authorization (BOLA).
Vulnerability: Unauthenticated API leaks OAuth credentials
A security researcher reported finding an API leaking OAuth2 credentials in plaintext. These credentials were part of a Client Credentials Grant flow, which is typically used for secure server-to-server communication.
OAuth is widely recommended as a secure framework for API authorization. But not all OAuth flows offer the same level of security, and poor implementation can introduce vulnerabilities, such as credential leakage or authorization bypasses. In this case, the client credentials should remain strictly confidential, but were strangely returned in the response from an unauthenticated API. This may have been implemented intentionally by the developer for the sake of convenience.
The vulnerability was uncovered by inspecting network traffic from a web application. Unfortunately, it’s a common misconception among developers that APIs embedded in trusted applications are inherently secure or hidden from attackers. As the researcher’s detailed walkthrough shows, insecure web APIs are not only visible but also easily exploitable.
Vulnerability: xAI LLMs exposed to long term abuse
Continuing on the topic of API credential vulnerabilities, a recent KrebsOnSecurity report reveals that a developer at Elon Musk’s xAI inadvertently exposed a private API key on GitHub. This key granted access to at least 60 private large language models (LLMs), including experimental and unreleased versions.
Some of these models were reportedly trained on proprietary data from SpaceX and Tesla, potentially exposing sensitive corporate information to anyone who came across the leaked key.
While the most critical failure was the exposure of the API key in a public repository, from an API security perspective, however, the situation was made significantly worse by the fact that the key remained active for two months after the issue was first reported. This demonstrates the risk of using long-lived API keys that lack an automatic expiration.
The recommended best practice is to use short-lived access tokens in place of static API keys. In the event of accidental exposure, these tokens limit the window of opportunity for attackers, helping to reduce the potential impact and the organization’s risk.
Article: API Sprawl and the case for governance
To wrap up this week, here’s an interesting article that explores the growing problem of API sprawl, where for example APIs are created and deployed without collaboration or oversight from security and operations teams.
As the author notes, API sprawl isn’t simply a matter of having too many APIs. The real issue lies in the way APIs are developed in silos, often without clear rules or shared standards. This leads to overlapping functionality, inconsistent documentation, and increased security vulnerabilities.
At the core of the problem is a lack of governance. Setting clear guidelines for how APIs are designed, shared, secured, and eventually retired, is the key. It means making sure that everyone is on the same page from the start and that there’s a process for keeping APIs consistent and manageable across the organization.
I noted one Ponemon report estimating that the average organization manages around 1,000 APIs, though in reality, I suspect the number is likely orders of magnitude higher for many organizations. A quick look through internal code repositories often reveals old API specifications, which can provide hints about the number of unmanaged APIs, as well as what an API does or what kind of security (if any) was added. These artefacts can serve as a useful view into past development practices, especially before any formal governance was put in place.
Meanwhile, without governance, APIs will continue to pile up fast and become hard to track or secure!
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
