What is API Sprawl?

If you’ve ever flown over Los Angeles, you’ll see a phenomenon known as “urban sprawl.” The city seems to extend in all directions, with little apparent planning. The results include inconvenient commutes, traffic jams and air pollution. IT has its own version of this problem. There can be server sprawl, for example, where IT departments deploy an excessive number of servers without much planning or coordination. Like urban sprawl, server sprawl causes problems like inefficient use of space and energy, along with needless administrative burdens.

Application programming interfaces (APIs), too, can be subject to sprawl. Indeed, in 2021, F5 engineer Rajesh Narayanan coined the phrase “API Sprawl” while predicting that today’s 200 million APIs will balloon to billions by the end of this decade. As he put it, “As APIs of all kinds proliferate, it will become common for organizations to reach a point where they’re unable to effectively manage and control them. This is API sprawl, the condition of having too many APIs of too many different kinds in too many different locations to get a handle on.”

What is API sprawl?

Before delving further into Narayanan’s concept, it’s worth taking a moment to review how APIs work. An API is software that enables two or more applications or data sources to communicate and inter-operate with one another. When your mobile banking app gets data from your retirement account at a different firm, it’s almost certainly using an API to do so. Thus, APIs are not just connections between software programs, they also link businesses and corporate workflows. 

APIs represent a break from the traditional monolithic approach to software. Instead, over the last decade or so, much of enterprise computing now comprises collections of applications and data sources strung together with APIs. There are some wonderful advantages to this approach, but also some rather serious downsides. API sprawl is one of them. 

In general, each API is built and managed by a dedicated team. They are responsible for keeping it working, updating it when necessary, and ensuring that it is accessed only by approved users. Reality inevitably intervenes, and in most organizations today there can be many, many “rogue” APIs that no one knows about or “zombie APIs” that remain in operation despite no longer being in use. Or, there may simply be APIs that are not well tracked. They’re just out there, forming an unwieldy sprawl that is inefficient and insecure.

What causes API sprawl?

A number of theories exist to explain API sprawl. Some believe that rapid growth in the number of APIs has led to sprawl. However, this was not inevitable. Rather, it seems that growth, coupled with organizational issues—along with the evolution of IT—creates conditions that result in API sprawl.

For example, when IT organizations migrate systems to the cloud, that can cause some APIs to be left behind without anyone knowing it. You might wonder how an API can get abandoned, but when you factor in the ceaseless churn that most organizations experience, it should be easy to see the problem. If person A was assigned to manage an API, but then got laid off or quit, then his replacement, person B, may not have any idea what APIs he or she is supposed to track. 

Changes in software architecture can contribute to API sprawl. Microservices, for instance, set up an environment where there are so many APIs that it becomes difficult to stay on top of all of them. Shifts in development methodology can compound this problem. With continuous integration/continuous deployment (CI/CD), to name but one example, developers gain the ability to push new APIs into production, or generate code that calls on new APIs, on a daily basis. If admins are not completely aware of the CI/CD pipeline, rogues and zombies will proliferate. 

Inconsistent or nonexistent standards are also to blame. If developers do not adhere to standards, the result can be different versions of the same API operating in parallel. Sprawl ensues.

How API sprawl affects your business

API sprawl is not good for your business. At a minimum, it drives up the cost of application development and IT management. An API that can’t be seen is an API that will be re-developed because no one knew it was already in existence. Admins will also spend time figuring out which version of an API is the right one to use, or waste time disconnecting software that’s calling on the wrong API. 

Revenue and reputation can suffer, as well. If customers have bad experiences interoperating with your software because API sprawl led to them calling on an out-of-date or non-functional API, they may not want to do business with you again. Or, if working with your APIs causes an undue burden on technical support, that will not be good for your business relationships, either. 

Security, however, is where API sprawl can do the most damage. APIs form a significant attack surface, given their ability to provide access to applications and data. The risks are bad enough with well-managed and defended APIs. 

When APIs are not well managed, or even known about, the vulnerability they represent grows all the more serious. If a hacker can access your data through a zombie API, you might not even know about an attack for weeks, if ever. An unattended API can be a pathway for a massive data breach and exfiltration.

Best practices to prevent API sprawl

It is possible to prevent API sprawl, or at least reel it back in if it’s gotten out of hand. This involves adopting best practices, the most important of which is to have a clear API governance strategy. API governance should include identifying who is responsible for API creation, the standards that need to be followed, how APIs will be used, and who should have access. API governance also needs to create policies for version control, monitoring and reporting. 

Implementing API governance has to start with an API inventory. This is often where the first surprises occur, with IT managers saying, “Oh, wow, I had no idea that API was still in operation.” With an accurate inventory, however, it becomes possible to cull rogue and zombie APIs. Admins can connect the most current API versions with API consumers, and so forth. 

It’s not a one-time process, either. There has to be a plan for ongoing management and governance of APIs. Ideally, the plan will be operationalized and included in the CI/CD pipeline and other elements of the software development lifecycle (SDLC).

A further best practice is to restrict the number of APIs that can be developed, and then managing them with a centralized API management platform. This enables admins to keep track of APIs in one place—the antithesis of sprawl. 

API governance to combat API sprawl is an organizational issue as much as it is a technical one. People need to be trained. Managers must create accountability for API sprawl issues among staff members that are responsible for API management. 

Additionally, it is critical for API security controls and countermeasures to be part of the effort to prevent or contain API sprawl. API security testing ought to be included in the CI/CD pipeline. API security has to be part of the overall API governance design and process. Controls might include rate limiting and preventing unauthorized access.

How Noname Security can help with API sprawl

Noname Security’s platform helps with API sprawl through its API discovery capabilities. The solution enables users to identify and document every API in its domain. In real-time, it can spot misconfigurations and vulnerabilities in the source code, along with problems in network configuration and policy that can affect security and manageability. 

The solution can also classify APIs by the kind of data they handle. For instance, if an API provides access to personally identifiable information (PII), which is covered by privacy regulations, Noname Security will flag it for compliance controls. It assesses API configuration so security managers will be aware of potential vulnerabilities. With these features, Noname Security gives you the ability to cut down on API sprawl and prevent it from recurring in the future.