As APIs grow exponentially in number and spread out across complicated web and mobile app ecosystems, businesses are increasingly challenged to achieve the visibility and control they need to spot code vulnerabilities that might open the door to threat activity.
A new report released this week by F5 Networks examines this phenomenon of API sprawl and how it can lead to hijacked and weaponized APIs or webhooks, stolen secrets, and fraudulent activity.
Co-authored by F5’s Rajesh Narayanan, senior director and distinguished technologist, and Mike Wiley, vice president and CTO of applications, the report says every API represents “a point on the security perimeter that can be potentially compromised if not properly architected or protected.”
The danger is real, the report states, because APIs from multiple sources are too often implemented and distributed without applying standardized best practices and governance. Other factors contributing to the sprawl are increased adoption of cloud-based services and microservices architectures, version control issues stemming from continuous software development, complex integration challenges, and siloed product and dev teams working on their own separate projects.
“As digital transformation has taken every company and turned them into a software company, each of these organizations has had to transition significant portions of their business to the cloud,” said Tyler Shields, CMO at JupiterOne. “In doing so they have to re-architect their applications and systems to better leverage the cloud, bringing in microservices and APIs throughout the infrastructure. This… is resulting in security difficulty in tracking the existence of this rapidly changing infrastructure in a programmatic way.”
“Just having visibility into the APIs in use is the first and most obvious security problem,” Shields continued. “From there, configuration, authentication and authorization and encryption are all significant security requirements that are difficult to meet.”
Jamie Boote, security consultant with the Synopsys Software Integrity Group, agreed that an increase in cloud computing and container-based microservice architectures “are putting unprecedented security pressures on teams. On top of the APIs themselves, “the microservice and container-based architectures that host APIs have brand new attack surfaces as well,” he noted. “The containers … may be vulnerable in how they build from outdated images or be bundled with secrets that could be extracted and re-used by attackers.”
What’s more, as an increasing number of organizations join the cloud craze, the definition of what cloud constitutes “has become increasingly abstracted,” said Michael Isbitski, technical evangelist at Salt Security. “Organizations also adopt other ‘flavors of cloud’ beyond just infrastructure-as-a-service. The list of infrastructure types can include managed container or Kubernetes platforms, low-code application platforms, and serverless or function-as-a-service platforms. Organizations also frequently consume software-as-a-service offerings to support their business. The large spectrum of compute and service types makes universal [API] visibility or control difficult for security teams to achieve.”
Another major contributor to sprawl, according to Isbitski: API protocol disparities. “REST still dominates, but GraphQL is also gaining adoption, as is gRPC within microservice architectures,” he noted.
F5 estimates the number of APIs that current exist worldwide is nearing the 200 million mark, and could approach 2 billion by 2030. Boote summed it up this way: “In the distributed API ecosystem, the chain really is only as strong as its weakest link and there are a lot more links to secure now.”
API visibility and asset management
With those daunting projections in mind, SC Media asked experts what are the toughest challenges associated with API visibility and asset management, and which security threats related to APIs are of gravest concern. After all, APIs aren’t always quite as simple to track as other assets like network-connected devices, web applications or sensitive data caches.
Indeed, “API discovery is not a resolved problem for most organizations,” said Boote. For starters, “there is no single tool that can accommodate every environment, language, framework or architecture,” which perhaps means investing in multiple solutions or services. “There may be solutions that work from developer-driven inputs and documentation. Automated QA testing may provide another source of endpoints. Yet others may be able to rely on API service discovery tools,” he explained.
Another issue is the extensive amount of ecosystem mapping that’s necessary to try to cover as much ground as possible when assessing the API landscape.
“Unlike web applications that are meant to be navigated by humans, APIs are designed with the understanding that any client would have to know all endpoints ahead of time. There is no list of links to navigate around on, there are no prompts that inform a potential tester about the nature of the data they are expected to input,” Boote explained. “Externally mapping and spidering an API without inside access to source code or memory space is either an exercise in futility or telepathy. Instead, API testers have to work with developers and system operators to build a map before they can even begin to run their traditional tests and tools.”
Third-party API partners are, of course, a significant part of this ecosystem — and the more there are, the more complicated this process becomes.
“Walk into any Fortune 500 company and ask, ‘Do you know where all your APIs are?’ and I can guarantee you’ll get a lot of sad looks. Because development nowadays almost requires the use of vendor APIs, it is impossible at this point to contain that,” said Boote’s colleague Michael Borohovski, director of software engineering at Synopsys Software Integrity Group. Consequently, “when using other companies’ APIs, you are relying on their ability to secure them. Unless you’re building everything yourself, you have to trust the vendors whose APIs you’re using.”
So what to do? Every solution to a complex problem has to start somewhere, and Boote says in this case it starts with building an organizational list of in-scope applications with API endpoints. “From there, applications within the scope are prioritized and grouped by documentation approach,” though it’s important to note that “not every approach works for every application.”
As companies get better at inventorying and securing their current array of APIs, they can also begin trying to shift lift by incorporating security into the app design and development process, said Boote. Still, they need to secure efficiently and effectively, with attacks on the upswing.
"The best thing that companies can do to combat this threat is to build a holistic API discovery, testing, and protection strategy that draws expertise and participation from designers, developers, testers and operators,” he said. “They also should consider prioritizing up-to-date API documentation and testing requirements for any API release moving forward.”
Borohovski agreed that dynamic testing and documentation is critical, and also advised that companies introduce automation into the testing process, “because it can be run more often, even as quickly as the deployments occur.”
Put all of that together, and you should make some significant headway in managing your sprawl: “The first step to any of this is ensuring proper documentation for every API that exists within a company, and for every API that is built in the future,” said Borohovski. “It should be a requirement that whenever a change is made to the API, the specification changes appropriately, as well. This is something developers want, because it helps them ensure APIs perform correctly. It also has the double-benefit of making it inherently more secure as well. You can use specifications with automated tools to parse API specifications and run audits on the actual APIs for both correctness and security, in development. If every company started requiring their vendors’ APIs to have consistent documentation and specification standards, the internet would be a much safer place."
Isbitski at Salt also suggested that organizations seek out new tooling “that integrates with the numerous technology stacks and varieties of compute that are used across all environments.”
“It’s not enough to deploy an API gateway or perimeter proxy and expect that it gives you the complete picture of your API traffic,” he continued. “Your systems, applications and APIs span many environments. Discovering all API assets requires that the organization gather telemetry at multiple points of its enterprise architecture. Protection requires that such tooling works in tandem with pre-existing network proxies and gateways to enforce the most appropriate type of mitigation, in the most appropriate point of an architecture, for a given API exploit or abuse.”
Furthermore, Isbitski said the tooling should be able to function right out of the box and “continuously learn the uniqueness of an organization’s environments and business logic. This end state can only be achieved with security tooling that is cloud-native itself and that makes ample use of AI/ML to analyze all API telemetry, produce meaningful signals for IT teams, and protect APIs accordingly.”
Without such improvements in technology and process, it’s very possible that certain API endpoints remain undocumented and unmanaged, operating in the shadows.
This is the “most dangerous type of risk to carry,” warned Boote. “Undocumented endpoints can’t be tested for API-based software vulnerabilities. They also can’t be protected by active monitoring and protection controls. When under-documented APIs are updated, previous versions may persist in production and provide entry points for attackers. If an undocumented endpoint is exploited, the company may not find out about such an event for months and only be able to understand the full extent after a lengthy forensic response.”
Indeed, the potential risks and ramifications of unmanaged API are not lost on the security community.
“With [API] sprawl comes opportunities for malicious actors to find gaps in your organizations software and services," said Ray Kelly, principal security engineer at NTT Application Security. “Exploiting these gaps in APIs can lead to vulnerabilities such as remote code execution or SQL Injection, both of which can have a catastrophic impact on the company as well as their customers.”
