This week, the theme is API authorization gone wrong. Guest contributor Rob Spectre kicks off a new interview series exploring real-world authorization failures. We also dive into case studies with key lessons for API security teams, including a look at the missteps that led to a £2.3M fine for 23andMe, and data exposure from the Asana MCP. Finally, we highlight a new resource on securing OAuth for cloud native APIs.
Case Study: True Nightmares of Authorization
By guest contributor Rob Spectre, DevRel at Oso.
It’s 5:45pm on a Friday. A small uptick in HTTP 400s and 500s pops up on an internal customer management tool. Within the hour, the entire engineering team at a hypergrowth startup scrambles to respond to a security intrusion – one that this technical leader will never forget.
Oso kicks off a new series called “True Nightmares of Authorization” in interviews with engineering and product professionals about some of the worst moments of their careers. The details and identities are kept confidential, but the stories – and the months of pain that followed – are real. Read the first one – The tale of the Pwned Password Pilferer.
Case Study: JWT Validation & Unauthorized Payments
Real-world incidents highlight why API security matters and can help to avoid repeating the costs and pains other API teams experienced as a result of a vulnerability.
The RSAC article by Ravi Teja Thutari “Three Outages That Changed How We Think About API Security” does exactly that, similar to the Oso series, by focusing on impact and lessons learned.
In the first case, a payments API failed to properly validate JWT access tokens due to a misconfiguration in an API Gateway. It’s a classic example of how a simple change can expose a serious vulnerability and highlights why defense-in-depth is crucial.
The second case involved an API bug that led to a service outage and denial-of-service (DOS).
While edge devices like gateways provide general rate-limiting, APIs often require more fine-grained protections tailored to the specific service they expose. For example, Auth APIs are often a target of brute-force attacks on login or one-time-password validation services, and benefit from tighter, API-specific restrictions.
The article contains some really useful insights, worth a read!
Article: 23andMe Fined £2.3M over API Breach
Still on API rate-limiting: the Guardian reports that the UKs Information Commissioners Office (ICO) has fined genetic testing company 23andMe £2.3 million for a 2023 data breach.
A threat actor used a credential stuffing attack against a login API, using stolen credentials to exfiltrate the private data of over 155,000 UK residents.
Delving into the ICO’s Penalty Notice, the company was primarily fined for inadequate security, lacking multi-factor authentication and, in particular, ineffective rate-limiting rules and alerts:
“organisations should ensure that they are rate-limiting or throttling the number and frequency of incorrect login attempts… limiting to a certain number per hour, day and month is a good idea.”
23andMe did apply IP-based rate limits, but this is (and was) easily bypassed using rotating IP addresses. More elaborate API security policies are needed, such as tracking login attempts per user and using device fingerprinting.
Behavioral analytics can also help flag unusual activity, but this approach tends to only react after suspicious activity emerges over time, making it useful for long-term damage limitation rather than stopping an attack early in real time.
Notably, 23andMe filed for bankruptcy protection in the US earlier this year.
Vulnerability: Bykea API Exposed by Classic BOLA Vulnerability
Strengthening the case for its top spot on the OWASP API Security Top 10, another Broken Object Level Authorization (BOLA) vulnerability has been reported, this time in an API belonging to ride-hailing and logistics company Bykea.
The security researcher provides a clear and well-documented walkthrough of the vulnerability and exploit, setting up “victim” and “attack” accounts to show how an attacker can easily access a victim’s data when API developers fail to implement proper object-level authorization checks.
In a nutshell, API developers must ensure that every request to access a resource includes a check to confirm the authenticated user has permission to access that specific object.
BOLA, a post-authentication vulnerability, is one of the most common and dangerous API vulnerabilities. Reducing the risk means raising developer awareness of secure coding practices, and QA teams adding identity-based automated tests to catch these security issues before production.
One to watch out for.
Vulnerability: Asana’s MCP Data Exposure
Staying on the topic of resource-based authorization: in the last issue of APISecurity.io we looked at the expanding usage of Model Context Protocol (MCP) to extend the capabilities of AI agents and servers through APIs, and its inherent risks from authorization vulnerabilities.
This week, Upguard reports a case of potential data exposure in Asana’s MCP server, where a bug may have exposed private data to other Asana users and organizations. As it is with API security, least privilege access will be a key concern when it comes to adopting and integrating MCP.
The MCP specification recommends OAuth for authorization. A section on ‘Security Best Practices’ describes and illustrates authorization flows between MCP clients and servers, third-party APIs and Authorization servers. It also outlines potential attacks targeting MCP implementations and recommended security measures.
The Asana incident doesn’t appear to be the result of an attack, rather an implementation bug that leaked unauthorized user data. Which may highlight the steep security challenges teams face with MCP adoption, including safe and secure implementation of OAuth-based flows.
Resource: Cloud Native Data Security with OAuth
Finally, this week, here’s a valuable new resource for anyone working on API security: Cloud Native Data Security with OAuth. The book by the team at Curity describes steps to implement OAuth, and outlines how access tokens, scopes and claims can be used for secure, fine-grained API authorization.
I’ve been referencing it recently while configuring authorization workflows and found it very useful, both as a refresher on core concepts and for understanding some of the more advanced aspects of securing cloud-native APIs across microservices or Kubernetes clusters.
Authorization issues remain one of the most persistent challenges for API teams, and more so now as new protocols like MCP enter the picture. As highlighted again in The New Stack’s recent article, OAuth plays a foundational role in securing AI agents that interact with APIs and services via MCP. Without securely designed APIs and well-implemented OAuth flows, there’s a real risk of data exposure, especially as LLMs start to access sensitive organization data.
This book is certainly one I’ll be adding to my API security library, highly recommended.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
