Security vulnerabilities in the application programming interfaces (APIs) powering modern digital services and applications have emerged as a major threat to enterprise systems and data.
A recent report from Wallarm showed a 21% increase in API-related flaws between Q2, 2024 and the end of the last quarter. Nearly one-third of them (32%) were associated with cloud infrastructure and cloud native applications and services. In addition to the increased volume, a high proportion of the vulnerabilities that Wallarm reviewed last quarter had severity scores of 7.5 or higher indicating growing risk for organizations from API use.
“In Q3 we saw API breaches driven by authentication and authorization issues, leaked API data, and classic injection attacks,” says Ivan Novikov, Founder and CEO of Wallarm. Significantly, while many of the vulnerabilities in OWASP’s list of Top 10 API vulnerabilities are server focused, Wallarm’s data showed an uptick in client side flaws like OAuth misconfiguration and cross-site issues, Novikov says. “It’s concerning because defenders are resource constrained and need to focus on the most important types of attacks,” Novikov says.
A continuing enterprise emphasis on API integration and functionality—over security—is exacerbating the issue. Less than four-in-ten (37%) organizations currently have formally incorporated security testing into their API lifecycle management practices, a study by Postman earlier this year found. “APIs are now a top target for malicious actors, making security and observability critical,” the report noted.
What are the major contributors to API security risks and what should organizations be doing to mitigate them?
Misconfigured APIs
Many API security issues in recent years have stemmed from relatively easily avoidable misconfigurations. Common examples include inadequate authentication and authorization, lack of input validation, improper rate limiting, inadequate logging and monitoring and exposing sensitive data through error messages. Such misconfigurations can have severe consequences.
For instance, Broken Object Level Authorization (BOLA) — or when an API does not properly validate user access to resources – can allow attackers to manipulate object IDs to access unauthorized data says Ankit Sobti, co-founder and CTO of Postman. Similarly, Broken User Authentication vulnerabilities, when an API fails to enforce proper authentication, often allow attackers to bypass authentication checks and gain unauthorized access to endpoints, he notes.
Organizations can mitigate such issues by implementing security best practices such as strict authorization checks, role-based access control, multifactor authentication, applying server-side data filtering and reviewing API responses for unnecessary data.
“Without proper rate limiting, APIs become vulnerable to abuse through techniques like brute force attacks or denial-of-service (DoS) attacks, which can overwhelm the service,” Sobti stresses.
The vast majority of API-related breaches over the last few years have resulted from poor posture governance, says Nick Rago, field CTO at Salt Security. In many instances, “the barrier to breach was pretty low and the attacker did not need any herculean effort to take advantage of a misconfigured API.”
Rago attributes the problem to a lack of proper oversight over API development and management. “Building a governance framework, centered around the creation of a corporate posture standard,” is an important first step. To alleviate risks, organizations need to implement capabilities for discovering API assets, assessing their security posture and remediating non-compliance as needed, Rago says.
Badly Designed APIs
Poorly designed APIs are another major driver of API security incidents, says Rago. These are APIs that do everything they are supposed to do, expect in a manner than an adversary can take advantage of, he says. “Think of APIs that return more information than an application needs, or APIs that can be scraped for information over time.“
Other examples include APIs that use unvalidated SQL inputs, expose implementation details or that are too complex and bloated, handle errors in an insecure manner or have inconsistent naming and structure.
A poorly designed API can also sometimes ignore business logic inconsistencies, Rago says. Examples include ecommerce APIs that allow users to manipulate prices or allow users to make modifications that enable overly permissive access to accounts and transactions to which they are not entitled. Imperva’s State of API Security 2024 report in fact, identified business logic abuse as the top attack on APIs last year. These attacks accounted for 27% of all API related attacks in 2023, an increase of some 10% over the prior year.
“Both, abuse of badly designed APIs or attacks leveraged against a business logic vulnerability can be addressed by leveraging specialized behavioral threat protection that can decipher not just anomalous usage, but discern malicious intent behind an API consumer,” Rago notes.
As Imperva’s vice president of API security Lebin Cheng, wrote in an op-ed earlier this year, poorly made API design decisions can have a lasting impact on organizations and their customers. APIs for instance could cause serious performance bottlenecks if developers fail to consider scalability requirements when designing them. Similarly, in focusing mostly on business needs, developers can often overlook common security issues—such as buffer overflow errors—during design time, Cheng wrote. “The issue of poor API design is further compounded by the fact that there are no strict standards for how APIs should be designed,” he said. “This leaves it up to individual developers to determine the best way to implement and develop APIs, which means that poor design decisions can easily slip through the cracks.”
Lack of Visibility
APIs have emerged as a top attack vector for threat actors because of their near ubiquitous use. Imperva’s research showed organizations on average have 613 API endpoints per account. The security vendor found API traffic in 2023 to account for 71% of all web traffic in 2023 with the average enterprise making 1.5 billion API calls year.
Despite the proliferating use, and the corresponding risk exposure, many organizations don’t have enough visibility over their APIs.
“New methods are required to discover and test APIs,” says Kimm Yeo solutions manager at Black Duck. Organizations need to start thinking about API security in a more proactive manner, Yeo advocates. That means implementing capabilities to discover and inspect APIs earlier in the software development lifecycle, she says. The goal should be to ensure APIs and applications are continuously tested before they get into production. “Today’s API security solutions largely focus on implementing API discovery during production [where] any critical alerts produced are difficult to trace to the code,” she says. This can make it impossible for developers to fix identified issues, she says.
The pressing issue at hand is the lack of inventory of all the APIs that are exposed to the outside world in most organizations, says Krishna Vishnubhotla, vice president of product strategy at Zimperium. “It’s critical to act quickly as bad actors are exploiting this gap,” he says. “The first step is to urgently discover and inventory all these public APIs, followed by immediate measures to secure them.
Inadequate Security Testing
Many organizations are failing to prioritize API security adequately and often underestimate the unique risks APIs pose. Postman’s survey found just 37% of organizations currently do automated scanning and regular penetration tests to try and catch API vulnerabilities earlier in the development lifecycle. Relatively few have integrated security testing and checks in their API development process or centralized API monitoring capabilities.
Organizations that embrace API-first strategies — where APIs are a priority focus during the software planning, design, architecture and development process—are seeing better success on the API security front, say Rago from Salt Security. “Those organizations typically enforce “spec first development” meaning an API must be “blueprinted” with Swagger or OAS and approved before a line of code is written,” he says. “You need to blueprint the hospital first and validate its construction against the plan before you let patients in. Seems obvious but in most organizations that is still not the way it works.”
API risks fall under two big categories: access and availability, Wallarm’s Novikov says. Attackers either gain access to something they shouldn’t, or they can take an API offline by impacting its availability. “There are lots of technical details about how they might accomplish these objectives, but they all bubble up to these two outcomes.”
At a high level the key protections against these risks is strong authentication and authorization across all API endpoints, he says. “That means knowing all the APIs you have, which should require authentication, strictly checking authorization on the server-side, and implementing advanced rate limiting to slow attackers down,” he advises. “These mitigations are best practices, but that doesn’t mean they’re common practices.”
https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt556bb85fc0185f9f/672408bc3d7a4f4b033b6058/api_Who_is_Danny_shutterstock.jpg?disable=upscale&width=1200&height=630&fit=crop
