Why API attacks are increasing and how to avoid them

Australian energy company Jemena has been using APIs, in some form, for about a decade. Its use of APIs -- application programming interfaces -- has jumped recently and is expected to increase fivefold over the next couple of years. “We’re quite early in our journey,” says Daniel Gordon, the company’s cybersecurity architecture lead. “Now everything is API first, versus maybe an afterthought.”

Jemena is using APIs to share information with business partners and in customer-facing applications, Gordon says. “Even market operators and regulators are moving toward APIs. There’s been a clear acceleration in the last year -- the API-ification of everything.”

Gordon sees this as creating new security concerns for the company. The thing about APIs is that they’re designed to provide efficient access to data. If an attacker is able to compromise an API, they could potentially exfiltrate massive amounts of data in a very short time.

The traditional approaches to web application security, which focus on preventing access by bots, don’t apply to API security since, by definition, all API requests are machine-to-machine. “We don’t have so much of a bot problem as a potential data leakage problem. That’s what we’re most worried about -- unfettered access to data," says Gordon. "Being an energy company, we hold a lot of personal information.”

Jemena is a 3,200-employee company that delivers electricity to more than 350,000 homes and businesses and delivers gas to more than 1.5 million customers. In addition to the usual personally identifiable information, there is also medically sensitive data, such as which customers have life support equipment or other special requirements. Some types of data are under regulatory constraints not to be sent overseas, or that can only be shared with certain known parties. “It gets tricky very fast,” says Gordon.

There are limits to the effectiveness of a WAF

The company’s web applications are protected by a web application firewall (WAF), but there are limits to what a WAF can do. “The profile of an API is different from what a WAF traditionally protects against,” Gordon says. “You do expect a high volume of requests, and a WAF doesn’t protect against business logic attacks.” Instead, what Jemena needed was a security tool that looks at the specifics of each API request, and the behavior of the machine that sent it, and can tell a good bot from a bad bot. “There are a lot older bot-blocking companies, but not a lot of native API security solutions,” Gordon says. Things could be changing. “We feel that the market is going to evolve a lot over the next year.”

Late last year, Jemena started looking for a solution that integrated with the security systems that the company already had in place and settled on Salt Security. The system takes a behavioral approach to API security. “You have to understand the shape of your data, and if the requests are coming in following the shape you expect,” Gordon says.

The new tool was able to learn the patterns of the company’s API traffic, figure out what a standard request looks like, then look for deviations from that pattern. It sits behind the web application firewall but also connects to the company’s security information and event management system, which is Splunk. “We didn’t want to have another pane of glass to look at,” he says. Salt does have its own dashboards, he adds. “But we don’t spend a lot of time in Salt itself -- we spend time in Splunk looking at what’s generated.”

One potential downside to the anomaly-detection approach to API security is that Web applications change frequently and so does the corresponding API traffic. Jemena hasn’t had the systems in place long enough to tell whether that’s going to be a problem, says Gordon. “We’re going to monitor things very closely as we grow our API volumes.”

Jemena isn’t the only company worrying about API security — and for good reason. APIs greatly expand the number of ways attackers can get at sensitive data and systems. They are particularly hard to secure. Fortunately, new technologies, including AI, are starting to help enterprises get a handle on this threat.

Recent API breaches underscore API risk

According to a May 2023 report by API security company FireTail, more than half a billion records have already been exposed via vulnerable APIs, and 2023 is on track to be a record-high year for API breaches. These are some of the most prominent events from this year:

• In January, we learned about API-related vulnerabilities at Toyota, Mercedes, BMW, and more than a dozen other car brands. The vulnerabilities in the telematics systems didn’t just expose customer data, though. “If an attacker were able to find vulnerabilities in the API endpoints that vehicle telematics systems used, they could honk the horn, flash the lights, remotely track, lock and unlock, and start and stop vehicles, completely remotely,” wrote researcher Sam Curry in his report.

• Also that month, T-Mobile admitted to the SEC that hackers had exploited an API to steal the data of 37 million customers. In February, Trustwave researchers discovered that Finsify’s Money Lover personal finance app exposed the email addresses and wallet names of its 5 million-plus users.

• This spring, CISA issued an advisory about Nexx garage door controllers and smart alarms. More than 40,000 devices were discovered to have several API vulnerabilities, meaning that attackers could steal personal information such as physical addresses, open garage doors, and turn off alarms.

• In June, Patchstack researchers reported that the most popular WooCommerce payment plugin for WordPress, the WooCommerce Stripe Gateway, had an API vulnerability that allowed unauthenticated users to view any order’s sensitive data, including emails and full addresses. At the time, the plugin had over 900,000 users, half of them on the vulnerable version.

• Also in June, a researcher at Eaton Works was able to compromise Honda’s lawn and garden dealer e-commerce platform API, allowing him to reset the password of any account, and gain access to full customer information, dealer information, payment keys, and internal financial reports. That added up to nearly 40,000 exposed records.

• This July, JumpCloud, which provides cloud-based directory-as-a-service software to more than 180,000 enterprises, changed its API keys “out of an abundance of caution relating to an ongoing incident.”

That’s just some of the vulnerabilities disclosed so far this year, and there’s no knowing how many vulnerabilities weren’t disclosed by companies. But we can guess. A Data Theorem report conducted by Enterprise Strategy Group surveyed nearly 400 organizations and found that 92% experienced at least one security incident related to insecure APIs in the past 12 months.

Why API security incidents are becoming more common

First, exposing APIs to network requests significantly increases the attack surface, says Johannes Ullrich, dean of research at the SANS Technology Institute. “An attack no longer needs access to the local system but can attack the API remotely,” he says.

Even worse, APIs are designed to be easy to find and use, Ullrich says. They’re “self-documenting” and are typically based on common standards. That makes them convenient for developers, but also prime targets for hackers. Since APIs are designed to help applications talk to one another, they often have access to core company data, such as financial information or transaction records. It’s not only the data itself that’s at risk. The API documentation can also give outsider insights into business logic, says Ullrich. “This insight may make finding weaknesses in the business process easier.”

Then there’s the quantity issue. Companies deploying cloud-based applications no longer deploy a single monolithic application with a single access point in and out. Instead, they’re built up of small components — dozens, hundreds, or even thousands of them -- that all communicate with each other via APIs. According to Salt Security’s March State of API Security Report, 59% of organizations manage more than 100 APIs -- 9% have over 1,000 -- and 27% have more than doubled their API count compared to last year. Sixteen percent of those APIs are now processing more than 500 million requests a month, up from 11% six months ago. Each of those API connections is a potential access point for a threat actor and needs to be secured, authenticated, and access controlled.

“Various standards are available, but they can be complex to implement,” says Ullrich. Take, for example, the OAuth authentication and authorization protocol, an open standard supported by Google, Microsoft, Facebook, and other major players for social authentication.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.”
8. 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.
9. 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.
10. 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.