This week, in our final 2025 issue of APISecurity.io, we look back at the five most frequent API vulnerabilities covered in the newsletter over the past 12 months. These issues highlight common mistakes teams make in API development and can help to spotlight where security efforts can deliver the biggest opportunity to reduce risk.
I’d like to wish all APISecurity.io followers the very best for the year ahead. No doubt we’ll have plenty more API security news and challenges to cover in 2026!
Vulnerability #1: Missing Authentication
Our most frequent API vulnerability this year was Missing Authentication. These are APIs that do not enforce authentication for sensitive operations, allowing anonymous users to access data or perform actions that should be restricted to authenticated users.
In 2024, this was our fifth most reported vulnerability. In 2025, it rises to number one, accounting for 17 percent of all API incidents covered.
One case from March illustrates the impact of missing authentication, when patient data in the UK healthcare system was reportedly exposed through an unauthenticated API. And in August, we covered a similar issue at Intel, where a ‘getAccessToken’ API endpoint would return valid tokens without requiring any authentication.
Keeping track of your API endpoints and continually verifying authentication controls, both pre-production and in production, can help API teams catch and plug this vulnerability.
Vulnerability #2: Broken Object Level Authorization
Broken Object Level Authorization, or BOLA, was second on our list of frequent API incidents. BOLA occurs when an API fails to verify whether a user is permitted to access a specific object. Attackers exploit this authorization vulnerability by manipulating identifiers in API requests, such as user IDs, account numbers, or other resource identifiers, in an attempt to access other users’ data. This has become a go-to tactic for API hackers and is something API developers should be aware of.
We saw many cases of BOLA incidents in 2025. One example from our September issue involved Growatt inverters used in industrial and commercial solar-powered systems. A BOLA flaw in the API allowed hackers to take control of solar-powered IoT devices inside users’ homes.
“The flawed API accepts a device ID parameter without verifying whether the current user is authorized for that device, a textbook case of Broken Object Level Authorization”
Also in September, we reviewed a researcher’s findings on a BOLA vulnerability in India’s Goods and Services Tax (GST) website. By manipulating API requests, users were able to access the tax information of private companies that should not have been accessible to them.
Authorization checks for individual resources are usually too fine-grained to offload to centralized platforms like API gateways or IAM products. So the responsibility sits with API developers to implement the proper checks at the API endpoint.
Vulnerability #3: Excessive Data Exposure
The majority of API data leaks we saw this year involved the exposure of unexpected or unauthorized properties in API responses. This aligns with OWASP’s API3:2023 Broken Object Property Level Authorization (I think the earlier 2019 name, Excessive Data Exposure, still describes the issue more clearly).
Excessive data exposure occurs when an API returns more properties than needed. This includes returning full objects or records when only a subset of fields is required, or failing to filter sensitive properties before sending a response.
In May, we covered a case involving Volkswagen’s connected vehicle system. A researcher found that an API response returned information that the app didn’t need, including plaintext secrets and passwords. And in October, we reported the case of a registration portal for Formula 1 drivers that leaked excessive data in an API response, giving researchers enough context to uncover a privilege escalation vulnerability.
We agree with the OWASP guidance for preventing excessive data exposure: define and enforce the data returned by every API method through a schema-based or contract-based response validation mechanism.
Vulnerability #4: Broken Function Level Authorization
Most of the Broken Function Level Authorization (BFLA) incidents we covered this year were basic errors in role-based access control at the API operation level. These occurred when functions intended for privileged users were accessible to roles with less permissions.
One example came from an August report on Securden’s Privileged Account Management platform, where a sensitive password backup function was available to users who were not administrators. In our March issue, we highlighted similar issues in the Zitadel platform, where 12 admin-level API endpoints were open to non-admin users.
Other common BFLA cases involved users being able to run specific API operations, such as PUT or DELETE, that should have been restricted to administrators.
Vulnerability #5: Broken Authentication
And finally, fifth on our list of the most common API vulnerabilities this year is Broken Authentication. This describes flaws where the authentication mechanism itself is poorly designed or implemented, allowing an API to accept requests without properly verifying the user.
In May, we covered an issue in a Volkswagen mobile application where a one-time password validation API was vulnerable to brute force attacks. In September, FlowiseAI, a platform for building AI agents, disclosed a flaw in its password reset process. The vulnerable API returned a reset token directly in the response, instead of following secure practices to send the token to a registered email address.
We intentionally separated Missing Authentication from Broken Authentication to highlight how often API teams completely fail to enforce authentication. Though challenges also remain prominent with API authentication controls generally.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
