API security strategies must evolve to include API protection
An API security strategy must include the ability to protect APIs post-deployment, but questions abound about ownership, which tools to use and how to get started.
A basic truism in IT is you can't protect what you don't know exists. Applicable to every facet of information security, the need for API security is front and center.
"If you don't know where your APIs are and don't know how many you have, you probably don't know what data is being transferred to them and how to access them," said Sandy Carielli, analyst at Forrester Research.
This is problematic not only because the number of APIs in enterprises is growing exponentially, but also because APIs are an increasingly popular attack vector. Shifts in the API security tool market and uncertainty about who is responsible for API security also make the problem more difficult to address.
One thing is certain: It's time for enterprises to get a handle on API security. The question is how.
Why the API explosion?
The snippets of code known as application programming interfaces enable two separate software programs to interact. They have revolutionized how applications are built and how data and services are delivered to and interacted with among partners, customers, external providers and internal workers. On the app dev side, APIs bring faster time to market, fewer coding requirements and simplification of complex interactions.
A 2021 survey by API security company Salt found its customers' overall API call rates grew by 141% over six months -- a percentage that will continue to grow as APIs become even more ubiquitous and necessary.
Websites, web applications, SaaS applications and mobile apps all use APIs. As their use skyrockets, so too will API use. IoT, cloud computing, microsegmentation and service mesh also affect the number of APIs in play. Use cases in financial services, retail and healthcare, among others, are all driving the exponential growth in APIs in today's digital world.
API security threats abound
Despite all the benefits of APIs, their security is a nagging question.
Because APIs are designed for ease of use for both the developers creating them and the customers and businesses using them, usability and availability are often a security tradeoff.
A 2020 Veracode and ESG survey found 48% of organizations regularly -- and knowingly -- push vulnerable code into production.
APIs are not necessarily difficult to secure, but they aren't always written and deployed with security top of mind. A 2020 survey from Veracode and Enterprise Strategy Group (ESG), a division of TechTarget, found 48% of organizations regularly -- and knowingly -- push vulnerable code into production. According to the research, 54% push the code to meet a deadline, 49% because they believe the code is low risk and 45% because the issues were discovered too late to fix them before deployment.
The velocity and volume of APIs being deployed also make them prone to common web application vulnerabilities, such as SQL injection, cross-site scripting and credential stuffing attacks, as well as distributed denial-of-service (DDoS) attacks and easily preventable issues, including hardcoded credentials.
If exploited, these vulnerabilities could spell danger.
Mark O'Neill
"The whole point of APIs is to open up access to applications and data," said Mark O'Neill, analyst at Gartner. This access is great for companies and their partners, developers and customers, but it's also music to an attacker's ears. "It creates a huge attack surface," O'Neill added.
The actual size of this attack surface is hard to estimate. The Salt survey reported the average number of APIs per respondent grew from 28 in July 2020 to 89 in June 2021. When asked how many APIs enterprises use, O'Neill estimated companies with 2,000 people may have 300 to 500. Carielli said some large enterprise clients report using tens of thousands of APIs. Yet, few companies can commit to a number or even begin to estimate how many APIs they use, she added.
Sandy Carielli
So, the message comes around again: You can't protect what you don't know exists. And that's a problem, especially because APIs are an easy entry point to potentially sensitive data if improperly protected and if they don't have authentication measures in place to control who accesses them.
"We made a prediction a few years ago that, by 2022, API attacks would become the most frequent attack vector for enterprise web applications," O'Neill said. "That is playing out now."
Indeed, the Salt survey respondents reported an average 12.22 million attack calls per month in June, up from 2.73 million attack calls per month in 2020.
According to a November 2021 Cloudentity report, 44% of enterprises experienced significant or substantial API issues over the last year that resulted in privacy concerns and data loss. Salt reported 94% of its survey respondents experienced an API security incident in a year (July 2020-July 2021).
Companies and agencies including Google, Cisco, Peloton, LinkedIn, Echelon, Twitter, GitLab, Facebook, Starbucks and the U.S. Postal Service all experienced attacks traced back to APIs. In addition, API vulnerabilities were discovered in the official COVID-19 tracing apps in India and Qatar.
Clearly, vulnerabilities are passing through IT teams' precautions and quality assurance procedures, as well as any security tools in place. APIs are becoming an infosec issue, and security teams are noticing.
The problem with API security
In the past, security teams weren't overly concerned with APIs.
"When we had monolithic web applications, there were fewer APIs. They weren't as publicly disclosed, and the data they were sharing was much more limited," Carielli said. "It was a lot easier to control."
At the time, IT teams thought they had API security covered with the API management tool or API gateway they already used that included some security features.
The problem is the security offered by API management tools or gateways is generally lacking. So, security teams started deploying web application firewalls (WAFs), which, while more security-centric than API management tools, focused on web app security instead of the machine-to-machine type of traffic that happens with APIs, O'Neill said.
In fact, 94% of Salt survey respondents who experienced an API security incident in the past year reported they had a WAF in place, and nearly all of them had an API gateway.
As the number of APIs in use grew -- along with the number of attackers targeting them -- security teams started to pay closer attention and asked more questions about their protection.
When asked by clients what they need to do to address API security, Carielli suggests organizations with a WAF ask what API support it offers, and those with an API gateway should ask how it is configured for security. But clients can rarely articulate which tools they have and how they're configured, Carielli said. This is often due to a question of ownership.
In general, IT and app dev teams build and deploy APIs. These teams, which usually report to the CIO, run the API management tools that have limited security capabilities. They also own some API security tools used during development. Security teams, which report into the CISO, are outside this process. They hardly ever work with these teams on application security and APIs, and they worry more about post-deployment API protection -- something most app dev teams aren't concerned with.
John Grady
To make matters worse, app development is decentralized in many modern application environments, said John Grady, analyst at ESG. This can make it difficult to know what APIs are in use, as can outsourcing some or all app dev processes and using open source code.
So, whose responsibility is it?
"There are some potential areas for uncertainty, confusion or downright conflict," Carielli said.
Underscoring that confusion, Salt survey respondents reported 21% of API security responsibility is on developers, 20% on the API team, 16% on the app sec team, 16% on DevSecOps, 11% on DevOps, 9% on infosec and 4% on the platform or product team.
O'Neill noted many security teams need to learn what APIs are before they can figure out how to secure them. As a result, all teams involved need to work with security to ensure API security and protection -- but it's not an easy alliance, he said.
API protection tools start to evolve -- slowly
Two changes are taking place in the API protection market.
First, specialty API products are becoming available from companies such as Salt Security, Cequence Security, 42Crunch and Wallarm. Carielli warned such products aren't one-stop solutions for API protection, however, but tools for specific API protection tasks, such as API discovery, API control and API traffic management.
A problem already plaguing the security industry is having too many tools and alerts -- and API security is no exception. A 2021 Fastly and ESG report found that, on average, companies were spending $2.6 million on 11 web app and API security tools annually.
This ushers in the second market change: the consolidation of post-deployment API security and API protection tools. While it's happening slowly, this convergence will enable better API visibility and stronger API protection, Grady said. It's no surprise that WAF and bot management vendors are at the forefront of this consolidation movement, he added.
"You still have legacy applications, and you still have traditional attacks. So, you still need WAF capabilities," he said. But, since traditional WAFs lack the API protection needed in today's environments, that's where they can be improved.
Vendors including Akamai, Imperva, Fastly, Citrix, Radware and Cloudflare all tout WAFs with integrated API protection features, marketing themselves under the Gartner-coined label web application and API protection (WAAP). Google Cloud also uses the term WAAP.
Coined in 2019, WAAP initially described cloud WAF services. It has evolved from solely cloud-based to a product suite with four core features:
WAF
API protection
bot mitigation/management
DDoS protection
Other common WAAP capabilities include next-generation WAF, runtime application self-protection, microservices protection, automation and analytics.
What's in a name?
Not everyone is sold on the WAAP acronym.
Palo Alto Networks calls a similar offering WAAS, which stands for web application and API security, while others are sticking to API protection or API protection platforms.
Carielli said she refers to the converging API security space as WAFs expanding to include APIs but differentiates it from API security tools, such as discovery tools or other specialty tools. "I see it as a sign of how the market is emerging and changing," she said. "So, I don't have a specific designation."
Grady sometimes leans toward calling API security and protection "modern application protection," staying away from application security, which can be confused with preproduction and testing. He's OK calling it web application and API protection but not necessarily WAAP.
"It ultimately identifies a need in the market, which is that applications are more reliant than ever on APIs," he said. "There's something worth talking about, and a lot is happening in this space. Whether we call it WAAP or not is a toss-up."
Beyond building their way into the space, many vendors are buying their way in, Carielli said. Multiple acquisitions took place in the past year, including Imperva's acquisition of CloudVector and F5's acquisition of Volterra.
But Carielli noted more than WAF expansion is needed to solve the API security issue. API management products and static and dynamic application security testing tools should also be building in more native API protection controls.
"Across the board, major app sec tooling has to expand to cover APIs," she said.
The OWASP API Security Top 10 outlines the top 10 security risks facing APIs.
Getting started with API protection
Analysts agree that API security and protection is an ongoing, multistep process that requires multiple tools across multiple groups in an enterprise. A comprehensive API security strategy must be created to protect these small yet necessary bits of code, or companies could face damaging and costly breaches.
The Salt survey found 62% of organizations have only a basic API strategy in place or none at all.
There are steps to take now for security teams that want to get ahead of API security vulnerabilities and threats, which should be teams at any company doing any kind of business online, Grady said. And, yes, it all goes back to knowing what needs protecting in the first place.
Step 1. API discovery
Forrester's Carielli suggests starting with API discovery.
Yet, the discovery of each and every API in use -- public-facing, internal, only used with trusted providers or external -- isn't an easy undertaking, O'Neill said.
API discovery must also be an ongoing, regular task, he said. "If your engineering team deploys a new version of a web application that includes a new API, you want a security person to see that."
Step 2. API inventory
An API inventory should follow API discovery. "Most organizations don't have a catalog or inventory of APIs, and that's a problem," O'Neill said.
Security teams should inventory APIs and document where they are, what they do and what they handle, Carielli said. Organizations should also consider whether sensitive data is transmitted through APIs or whether an API gateway is in use, O'Neill added.
Step 3. API risk assessment
From there, perform a risk assessment to establish whether the APIs are vulnerable to known risks, such as those listed on the Open Web Application Security Project's API Security Top 10 list. The API risk assessment should also identify what would be impacted if a given AI is compromised and steps to reduce that risk. As with API discovery, API inventories should be repeated regularly, in addition to whenever new or updated APIs go into production.
Mark O'Neill
Sandy Carielli
John Grady
