This week, we dive into an unusual case of humans spoofing AI. We also examine three real-world API incidents of OWASP API Security Top 10 vulnerabilities. Plus, we share insights from a new industry report on rising API attack trends and explore how GitHub’s MCP vulnerability may signal a new set of authorization challenges to come.
Article: Heavy on artificial, light on intelligence
A recent report about Builder.ai, a startup alleged to have falsely marketed its product “Natasha” as an autonomous AI software developer, is a clear warning about the dangers of AI hype. Despite the company’s public claims of delivering an AI-driven software generation service, it was actually a team of 700 human developers behind the scenes doing the work.
The incident exposes a deep industry problem: the wildly unrealistic expectations placed on AI. Even leading AI companies are more realistic about AI’s limitations. For example, in a recent article “Anthropic’s AI is writing its own blog — with human oversight”, Anthrophic admits using experts to review AI output before publishing even a blog post!
So the idea that AI is ready to autonomously write complex production-ready software, or for that matter to automatically secure API transactions in real-time, without human oversight is, frankly, pure fantasy.
AI can be a tool for developers, not a replacement for developers. As this incident shows, it’s time to ground discussions about AI in reality.
Vulnerability: Mozilla API flaw allows malicious account deletion
A security researcher ethically disclosed a high severity vulnerability discovered in Mozilla’s account deletion API. The flaw allowed an authenticated user to delete other user’s accounts simply by substituting their email address in the API request.
This is a textbook case of Broken Object level authorization (BOLA), the top-ranked issue on the OWASP API vulnerability list (OWASP API 01:2023). BOLA occurs when the developer fails to properly check if a user is authorized to access or manipulate a specific resource.
For API authorization, it’s often not enough to verify the user’s authentication and role; developers must ensure the user is also authorized for the specific resource being requested. Without that important check in the API code, a threat actor can exploit the API by changing object identifiers in the API request, such as email addresses or user IDs, to point to another user’s resources.
Mozilla awarded the researcher a $6,000 bug bounty, highlighting the importance of testing for proper authorization checks during API development.
Vulnerability: 50,000 Azure AD users exposed via unsecured API
Researchers discovered an unsecured API endpoint exposing data on over 50,000 employees at a major aviation company. The API issued access tokens for Microsoft Graph without requiring authentication (OWASP API 02:2023), allowing anyone to query the company’s Microsoft Graph APIs and retrieve employee records and identity data.
The vulnerable API was embedded in a public Javascript file, and developers may have assumed the API didn’t require authentication because it was only intended for use by a trusted web client. But as we previously highlighted for similar cases (Issue 270 “Unprotected APIs expose 33,000 employees”), it’s trivial for hackers to find these vulnerable APIs on websites and mobile apps, and exploit them.
The key lesson is that all API endpoints must be individually secured, regardless of their intended use. Public-facing APIs are always discoverable and exploitable. API authentication, access control and server-side input validation are essential. Obscurity is certainly not security.
Vulnerability: Recruiter emails leaked in API response
A vulnerability in an API used by Naukri, a popular job search platform in India, exposed the email addresses of recruiters viewing job candidates profiles.
Security researcher Lohith Gowda discovered that when candidate profiles were retrieved, recruiter emails were unnecessarily included in the API response; a classic case of excessive data exposure (OWASP API 03:2023).
While leaking recruiters’ email addresses might seem low-risk, it does reveal sensitive context, such as which recruiters are interested in which candidates. This opens the door to targeted spam, social engineering, or spear phishing campaigns.
Developers are often advised to apply the principle of least privilege when coding an API’s response data, only returning the data strictly required and authorized for the client.
Industry Report: 78% of API attacks happen after authentication
A recent report by CDNetworks reveals that 78% of API attacks occur after successful authentication. Attackers are using valid credentials, whether through stolen API keys, hijacked sessions, weak passwords, or even newly created accounts, to launch their attacks from inside the target system.
Once a user is authenticated and access is granted, the next line of defense is authorization and API data governance.
Role-based authorization (RBAC) helps to limit what authenticated users can see or do.
Resource-level authorization, such as protections against BOLA vulnerabilities, helps to prevent lateral movement within the system, ensuring users can only access resources explicitly tied to their account. This can significantly reduce the impact of attacks by authenticated users.
The report also cites Gartner’s Market Guide for API Protection, which notes that the average API breach exposes at least 10 times more data than a typical security breach. This increased risk stems from the fact that every API exposes unique data properties, requiring tailored security measures at the API level.
This can be addressed with strong API design and runtime data validation, using developer-defined data schemas to reject unexpected or malformed data, and block common API logic abuse and injection attacks.
Vulnerability: Does MCP pave over the cracks in API security?
The recent GitHub MCP server vulnerability highlights a growing and perhaps underappreciated risk: resource-based authorization remains a largely unsolved problem, at both the API layer and now at the emerging abstraction layer introduced by MCP (Model Context Protocol).
APIs have long struggled with Broken Object Level Authorization (BOLA), where attackers exploit insufficient authorization checks to access private resources. These vulnerabilities are inherently context-specific, and solutions must be customized for each API’s unique data structures, user roles, and business logic.
Just like APIs, authorization in MCPs will be highly context-specific. What an agent should be allowed to access in one scenario may be entirely inappropriate in another. This makes it unlikely that a universal, one-size-fits-all authorization model for MCPs will succeed, just as it doesn’t work for APIs. Instead, both layers will need fine-grained, customized authorization policies. There’s some work to be done by developers here.
As we scale the use of MCPs in AI-driven systems, the industry should ask: Are we solving API authorization vulnerabilities, or simply paving over them with a new surface of AI-native ones?
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
