Some 66% of organizations say they have slowed deploying an app into production because of API security concerns.
For the second time in recent months, researchers are sounding the alarm on threats to enterprise security from insecure application programming interfaces (APIs).
Last November, analyst firm Forrester Research warned about organizations failing to address API vulnerabilities in the same manner they did with application vulnerabilities – and their growing exposure to API-related breaches as a result.
This week, Salt Security released a report on API security that combined responses from a survey the vendor conducted of 200 IT and security professionals with empirical data from the company’s customers.
The results show that 91% of organizations in the survey suffered an API-related problem last year. More than half (54%) reported finding vulnerabilities in their APIs, 46% pointed to authentication issues, and 20% described problems caused by bots and data scraping tools.
“The most common API security incident reported for 2020 was finding a vulnerability in a production API,” says Michelle McLean, a vice president at Salt Security.
That finding shows that as much as organizations are applying “shift left” principles and integrating security controls earlier into the development life cycle, the effort is still not enough.
“Organizations need to complement the security tactics they apply during build and deploy with runtime security,” McLean says.
The second most common incident centered around authentication problems in which attackers were able to manipulate authentication in some way to try and gain access to sensitive data. Other common issues included account misuse and denial-of-service attacks, where attackers launch enough manipulated API traffic to try and disrupt the apps behind the APIs.
“APIs present a significant risk to organizations,” McLean notes. “Attackers are taking advantage of them now, and current strategies and technologies are not providing sufficient protection.”
APIs allow applications and application components to communicate with each other on internal networks and, increasingly, over the Internet. Initially, APIs were typically used on secure private networks and communications channels. These days they have become integral to enterprise efforts to make internal applications and legacy systems and services accessible over the Internet to business customers, partners, suppliers, and other third parties. An organization can have dozens, hundreds, and even thousands of APIs connecting internal apps to each other and the outside world. Analysts have noted how APIs can provide a direct gateway from the outside to an organization’s critical data and applications if not properly secured.
The most common way attackers are exploiting API vulnerabilities is by manipulating the objects — such as a user ID number — that an API might have the authority to access.
“They authenticate to the application, start the communications using their own user ID, and then in the midst of a subsequent API call, they change that object to a different user ID,” McLean says as one example. “Now the attackers can access sensitive information associated with that other ID.”
API Security Concerns Mount
Salt Security’s survey found that two-thirds of organizations have slowed the rollout of a new application into production because of API-security related concerns. The company’s customer data shows the number of API attacks per month per customer jumped from 50 last June to nearly 80 in December. While the average monthly volume of API calls at Salt Security’s customers grew 51%, the percentage of malicious traffic soared 211% over the period of the study.
McLean says that malicious API traffic in this context relates to activities by attackers to reach the data that APIs connect to or to disrupt the services they enable. As examples, she points to attempts by attackers to change account numbers in the middle of an API call or to manipulate API calls to insert hundreds or thousands of potential credentials in hopes that some match existing credentials.
Despite these trends, Salt Security’s survey also shows what appears to be a relatively blasé approach to the problem at many organizations: More than one-quarter (27%) admitted to having no strategy at all for dealing with API security, and 54% described their strategy as being basic at best. Eighty-three percent admitted to being unsure about their API inventory, and 82% lacked confidence in their knowledge about APIs that exposed PII, cardholder data, and other sensitive information.
More than one in five admitted to having no way to know which of their APIs exposed personally identifiable information, and many said their biggest concern was the prevalence of outdated and zombie APIs on the network.
Addressing these issues requires a solid API security strategy, McLean says. That means having mechanisms for protecting APIs across their full life cycle, she says. Organizations need to have controls for validating APIs during the build phase, deploy phase, and while they are running in production.
Organizations should also consider fostering collaboration between the groups writing APIs and the groups chartered with protecting the data and the services to which the APIs connect, she says.
“Developers aren’t trained to think like an attacker the way security teams are, and security teams aren’t coding every day, so they don’t understand API constructs as much,” McLean says.
It’s only by ensuring the two groups work together that organizations can fully protect enterprise APIs, she adds.
Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio