This spring, researchers at Salt Security found that it was easy to make mistakes implementing this protocol. The travel site Booking.com, for example, allowed unauthorized people to use Facebook logins to get into anyone’s Booking.com account. In addition, according to Salt Security’s March API security report, 78% of API-related attacks came from attackers who maliciously achieved legitimate-seeming authentication.
Then there’s the serialization problem. That’s when a file is broken up into smaller pieces so that it can be transmitted by the API. Each individual piece might be harmless on its own, but, when reconstructed back into a complete object, it might turn out to be a piece of malware. “This has led to deserialization vulnerabilities that allow attackers to execute arbitrary code,” says Ullrich.
Finally, the ease of deploying and updating APIs means that security teams aren’t always as “in the loop” as they should be. According to the ESG survey, 75% of organizations update their APIs weekly or even more frequently. “In some cases, it may not even be known that an API exists,” says Ullrich. This creates a new type of shadow IT — shadow APIs — which is not properly protected, monitored, and controlled.
That’s a hard problem to address. “When we think of cloud-native development, developers don’t have to go to IT to provision their compute resources,” says ESG analyst Melinda Marks. “They build it themselves. A lot of times, they’re under pressure to meet their delivery timelines. And then they update, update, update. People deploy even knowing there’s a vulnerability because they think they can fix it before attackers can recognize it.”
That exposes organizations to a lot of risk, Marks says. Those risks don’t go away when an API is no longer used. According to the Salt survey, 54% of companies are highly concerned about outdated or “zombie” APIs. These are connections that are no longer used or managed but weren’t properly decommissioned so attackers may still be able to exploit them.
API security challenges
The size, complexity and fast-changing nature of the API ecosystem creates several major security challenges. The top concern, Marks says, is authentication. “That’s such a basic thing for any type of connection,” she says. “Make sure it’s authenticated.”
Authentication and authorization issues account for four of the OWASP Top 10 API Security Risks, which were updated this July (see below). According to the FireTail API Data Breach Tracker, each of the 12 public API breaches so far this year involved at least one authentication or authorization vulnerability.
As the Bookings.com problem with OAuth demonstrated, it’s easy to get authentication wrong. According to the ESG survey, problems with API authentication were the biggest concern companies had about deploying APIs, with 88% of respondents saying that it was a significant or moderate concern.
Another issue is identifying the critical data and how it moves through the API ecosystem. Marks recommends that enterprises figure out where their most sensitive data is to prioritize API security based on which ones have access to that data. Unfortunately, companies typically do this manually, which is a slow and error-prone process. “You really need automation and tools and processes to make sure you can find the APIs and understand the relationships between the APIs and what they’re connecting to,” she says.
This lack of visibility is a major problem for companies for both internal APIs and third-party APIs. “You can’t secure what you can’t see,” Marks says. “Getting all the information together to give them some kind of idea about what they need to address most urgently is a big problem.”
Finally, the security tools that companies do have often aren’t working. According to the ESG survey, 74% of organizations say they have a robust API security program in place with multiple web application tools. API security tools are used by 59% of organizations, 57% have web application firewalls in place, 50% have API gateways, 48% use distributed denial of service mitigation, and 42% use bot management tools. “We ask about what solution they have in place for API security, and they’re checking off that they use all of them and saying that they’re effective,” says Marks.
Does the number of breaches go down as enterprises deploy more security tools? No, says Marks. In fact, according to the survey, the presence of multiple API management tools is the biggest security challenge, just ahead of lack of visibility into API deployment, inaccurate inventories of third-party APIs, inconsistent use of API specifications, and lack of ability for developers to do security testing of their APIs prior to deployment.
“With multiple tools, you get multiple alerts,” says Marks. “They’re built in different languages, and with multiple tools, it takes longer to deploy them, manage them, and train people on them.”
OWASP API Top Ten API Risks
- Broken object-level authorization: Developers should check that the user has permission to perform the actions they want to perform on an object. When these checks are missing, the vulnerability is easy to exploit. It’s also widely prevalent and easy to find and can lead to data loss or even full account takeover.
- Broken authentication: Examples of broken authentication are when applications permit credential stuffing or brute-force attacks, when users are allowed to use weak passwords, or when sensitive authentication details, such as authorization tokens and passwords, are embedded in the URL. This vulnerability is easy to detect and exploit, is common, and can lead to severe business impact.
- Broken object property level authorization: This is another vulnerability that is easy to detect, easy to exploit, and is commonly found in the wild. One example of this is a booking app API that allows the host not only to agree to a booking but to change the price of the booking, charging the guest more than they expected. The problem here is that even when users are allowed access to particular objects, they might not necessarily need access to all the properties of those objects. OWASP recommends that the data returned by the API should be kept to the absolute minimum required for each individual use type, and the user’s ability to modify the object should also be kept to a minimum.
- Unrestricted resource consumption: Responding to API requests uses resources like bandwidth, CPU, memory, and storage. If there are no restrictions, successful attacks could make the system unavailable — a DDoS attack — or cost a company money. Say, for example, a password reset request involves the company sending out a text message. An attacker could request thousands of password resets via a script and the company would rack up a huge texting bill. Or attackers could take advantage of vulnerable APIs and upload large numbers of, say, profile images, using all available storage space. The solution is to put limits on uploads, interactions, and spending limits. This vulnerability is easy to detect, widely prevalent, and of average difficulty to exploit, but the business impact could be severe.
- Broken function level authorization: This is when API calls to specific functions don’t check that the user has the right privileges. For example, a low-level user might be able to create a new user account with administrative privileges. The solution is to have role-based authentication for each business function. According to OWASP, this vulnerability is easy for an attacker to detect, easy to exploit, and is common, while the impact can be severe.
- Unrestricted access to sensitive business flows: A new addition in 2023, this is when the requests are completely legitimate, but too many of them can cause harm. For example, someone might purchase all available tickets to resell them later for a higher price, flood a comment system with spam, or use a reservation tool to reserve all available time slots. This vulnerability is easy to exploit, widely prevalent, and takes only average skill to detect.
- Server-side request forgery: A new addition in 2023, this is when a user is allowed to supply a URL — for example, instead of uploading a profile photo, they can put in a URL to where their photo is located online. If the attacker supplies a URL that’s behind the company’s firewall and the API has access to those resources, then the user can piggyback on the API’s access permissions to get to content they’re not allowed to have. According to OWASP, this vulnerability is easy to detect, easy to exploit, is common, and can have moderate impact.
“I essentially order, in an authorized manner, the application to send requests on my behalf, but from its own permissions,” says Ory Segal, CTO for Prisma Cloud at Palo Alto Networks. It can be used to proxy requests so that they can fetch very sensitive data or, say, access your cloud provider’s metadata service. “One known example where this was abused was the 2019 Capital One breach,” he says. “It allowed the attacker to fetch the session tokens of the workload and using that they continued to impersonate the workload from their own external laptop. It allowed them to find S3 data that contained credit card information.”
- Security misconfiguration: APIs can be missing security patches, have out-of-date systems or improperly configured cloud permissions, be missing encryption, or have error messages that expose sensitive information. According to OWASP, this is a widespread vulnerability that’s easy to detect and exploit and can have severe consequences.
- Improper inventory management: This one is all about API visibility. Do you know the purpose of the API? Where is it running? Which version is it on? When is it scheduled to retire? Who’s supposed to have access to it? APIs can also have data flow blindspots, like not knowing that an API can access sensitive data and send it to a third party that shouldn’t have the data. According to OWASP, this is a widespread vulnerability that’s easy to exploit, has an average level of difficulty when it comes to detecting it, and has moderate consequences.
- Unsafe consumption of APIs: A new addition in 2023, this is when a company trusts external APIs more than it should. If the third party is compromised, that external API could send in bad data — like SQL injection attacks, or a redirect to a malicious location. According to OWASP, this is a common vulnerability that’s easy to exploit, has an average level of difficulty when it comes to detecting it, and has severe consequences.
The future of API security
Enterprises are looking toward platform-based approaches to API security, says Marks, to reduce the complexity and management overhead of dealing with different systems. “It’s all about efficiency, lowering costs, and breaking down silos,” she says.
Alert fatigue is also pushing companies towards consolidation, Marks says, as well as the cybersecurity skills gap. The industry is also looking toward artificial intelligence to improve API security, including the latest incarnation, generative AI. “It’s good to think about applying this technology in ways that will help with productivity and simplifying manual and lower-level tasks,” she says, but she warns against moving too fast with the technology.
Many companies, for example, were slow to enable auto-remediation and let AI systems automatically fix issues for fear that they would break applications. “But now, with certain things, they are willing to hit auto-remediate because of the trust in the tools,” Marks says. It will take time for the security tools to improve. Until they do, we can expect things to get worse before they get better.
According to Akamai, 2022 saw a record-high volume of API attack traffic, 2.5 times that of the previous year, with daily volumes regularly exceeding the 100 million attack mark in the second half of the year. Attackers have an increasing number of tools at their disposal, says Boaz Gelbord, CSO at Akamai Technologies. That includes AI, he says. Alex Marks-Bluth, a senior lead security researcher at Akamai, says that 31% of all attack traffic is now via APIs. Previously, Akamai had reported that 83% of all web traffic was APIs. The new statistic is lower because it only focuses on attack traffic, and it’s skewed down because of high-volume DDoS attacks which are not typically classified as APIs. In addition, Akamai is using a narrow definition of API traffic, Marks-Bluth adds.
When it comes to going after APIs, attackers have an increasing number of tools at their disposal, says Akamai CSO Boaz Gelbord. That includes AI, he says. It’s difficult to tell when an API attack is aided by AI — it’s more obvious when it comes to phishing or social engineering, he says. It’s still early. “We’re not seeing it today being used in large-scale, visible ways,” he says, “but I don’t think as a security community we should take too much comfort in that fact, because the wave is coming.”
It’s difficult to tell when an API attack is aided by AI. It’s more obvious when it comes to phishing or social engineering. It’s still early. “We’re not seeing it today being used in large-scale, visible ways,” Gelbord says, “but I don’t think as a security community we should take too much comfort in that fact because the wave is coming.”
Meanwhile, Salt Security’s March API security report showed that the number of unique attackers targeting company API has skyrocketed. The company tracked 123 attackers at the start of 2022. The number rose to 497 by June. Then, in December, there were 4,842 unique attackers being tracked.
Salt Security also conducts investigations and found that in 90% of cases the company had API security vulnerabilities, 50% of which were critical. As a result of these challenges, 59% of companies say that they have slowed the deployment of a new application because of API security concerns, and 48% say that API security is now a C-level discussion topic.
