This week, our theme is API authorization vulnerabilities. We cover critical issues discovered in the WSO2 API Manager and the Better-Auth plugin, share an eye-opening BOPLA vulnerability in a Formula 1 registration API, and examine familiar API security flaws appearing more often in industrial devices. We also highlight a recent interview with former CISA director Jen Easterly about the potential, and risks, of using AI to solve today’s security challenges.
Article: Is AI the silver bullet for software vulnerabilities?
In a recent article, former CISA Director Jen Easterly highlights some uncomfortable truths:
“The common factors uncovered by MITRE nearly 20 years ago – cross-site scripting, memory unsafe coding, SQL injection, directory traversal – remain part and parcel of shipped software.”
This aligns closely with our research at APISecurity.io. Over the past year, roughly 25% of all API security cases we’ve covered involved injection attacks, path traversal, or server-side request forgery (SSRF). These are long-standing, well-known vulnerabilities that existed long before web APIs were a thing, yet they continue to appear in production APIs.
Easterly suggests AI could help, though with important caveats:
“If we’re able to build and deploy and govern these incredibly powerful technologies in a secure way, I believe it will lead to the end of cybersecurity.”
The reality today though is miles away from this ideal. A 2025 GitHub survey found that most experienced developers do not trust AI-generated code. And two frustrations stood out: 66% of developers struggle with AI solutions that are “almost right, but not quite,” and 45% find debugging AI-generated code more time-consuming than writing it manually.
AI, like any security tool, is not a magic wand. But it can be effective if it’s placed in the hands of experienced developers to help automate practices and processes intelligently. As Jen Easterly emphasizes, real security comes from building systems securely from the start. Without the software engineering discipline, AI is more likely to amplify vulnerabilities and frustrations than prevent them. Read the article.
Vulnerability: Racing to an F1 authorization vulnerability
Fancy becoming a registered Formula 1 driver? There’s a vulnerable API for that!
Researchers Ian Carroll, Gal Nagli, and Sam Curry, recently uncovered a number of API flaws in the registration portal of Fédération Internationale de l’Automobile (FIA), the governing body for world motorsport. One API allowed users to elevate their role to administrator, and get access to privileged services and sensitive data, including the personally identifiable information (PII) of Dutch F1 driver Max Verstappen!
Two classic OWASP API vulnerabilities were exploited. First, excessive data exposure in the response to an API PUT request leaked “hidden” properties, like user role and status. Using those properties, the researchers then attempted an API mass assignment attack to change their user role to administrator, and it worked!
Excessive data exposure and mass assignment vulnerabilities are together categorized as Broken Object Property Level Authorization (BOPLA) in the latest OWASP API vulnerability list.
This case is another useful lesson on the need to tightly constrain an API’s allowed input and output properties, using schemas or API specifications. Otherwise hackers, ethical or otherwise, will find vulnerable entry points to exploit. Read the report.
Vulnerability: Better-Auth’s API coding error
Better-Auth, a popular open-source plugin for authentication and authorization, was recently found to have a critical API vulnerability. A logic error in the service for API key creation allowed any user to retrieve a valid API key for any other registered user, without needing their credentials.
In the code, if a request for an API key includes either a valid session or a valid user ID, the API skips authentication. That means if an unauthenticated user knows or can guess another user’s ID, they can send just the ID to the API and will receive back an API key for that user. If you’re interested in the technical details you can see the GitHub code comparison highlighting the logic flaw and its fix.
Missing or broken authentication is a common API vulnerability, and attackers often look for “enabling vulnerabilities” like logic flaws to bypass access controls. These issues can be especially tricky to detect because every API has unique input properties and security checks, and bypass mechanisms are typically very specific to the developer and the logic they code. Careful API design and early testing of the API logic can help prevent or detect these types of vulnerabilities early on. Read the article.
Vulnerability: Broken authentication in WSO2 API Manager
WSO2 API Manager uses method contexts to define and apply security rules for API operations. The rules set out:
- context = which URL or endpoint the rule applies to
- http_method = which HTTP method (GET, POST, PUT, DELETE, etc.)
- secure = whether this endpoint requires authentication
- permissions = which user roles or permissions are allowed
- scopes = which OAuth2 scopes are required for access
Some of the API platform’s own APIs were missing these method contexts (you can see examples here), exposing administrator-level operations without any authentication or authorization.
“The successful exploitation of this vulnerability could allow an attacker to gain administrative privileges and perform unauthorized operations.”
This case highlights the importance of verifying that every API endpoint requiring authentication and authorization actually enforces it. Testing should happen both before API deployment and continually in production to catch any changes or drift in APIs access control behavior. Read the advisory.
Vulnerability: Industrial System’s BFLA Vulnerability
Moxa is a provider of industrial networking solutions. They recently released a security advisory that included four API vulnerabilities in their network security appliances and routers.
Modern industrial devices often expose APIs for remote configuration, administration portals, or monitoring apps. API security incidents in industrial systems are relatively new, but we’re seeing cases more frequently as these systems become increasingly interconnected.
It’s also noticeable that the same API vulnerabilities commonly seen in web applications also appear in industrial APIs. Like the previous cases we looked at earlier for WSO2 API Manager and the Better-Auth plugin, Moxa’s “protected” APIs were missing authorization controls.
“A flaw in the API authentication mechanism allows unauthorized access to protected API endpoints, including those intended for administrative functions.”
Without authorization checks, low-privileged users could access administrator-level functions to modify system configurations, perform internal network reconnaissance, and even create new administrator accounts. That’s a classic case of Broken Function Level Authorization, another common API vulnerability that escapes the attention of API teams. Read the advisory.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
