George Lawton
A shadow API is one that lives outside the normal IT governance management and security processes. They are often undocumented, creating massive security and governance risks for organizations since teams lack visibility into how data and applications may be accessed by third parties.
At the very least a shadow API presents a governance issue, since well-meaning developers may violate local privacy mandates. In the worst cases, shadow APIs open a door for hackers to steal valuable data or compromise enterprise applications.
There are many ways that APIs can settle into the dark corners of your IT infrastructure. They could have been deliberately created by developers rushing to get a new project finished. Shadow APIs also include zombie APIs that may have been deliberately or accidentally left running at the end of useful life.
Sometimes shadow APIs started as fully managed APIs that were essentially copied over to support other services and used in an unmanaged way. One big concern is that attackers can gain access to these older API endpoints and request access to other services. This may also enable hackers to execute account takeovers through the older unpatched versions of APIs hiding in the shadows.
Shadows in the Cloud
The term “shadow API” probably emerged from the notion of “shadow IT” used to describe the way business users could spin up new IT infrastructure with the swipe of a credit card and outside the purview of the IT department. It is conceivable these tools could enable business users to create shadow APIs without appropriate guardrails.
Security experts have also raised concerns recently about shadow AI, in which business users find innovative ways to weave enterprise data into best-of-breed artificial intelligence services. The concern is that business users are not security experts and the rise of tools that enable citizen developers and citizen integrators pose a potential security risk despite the best of intentions.
In general, shadow APIs tend to be the result of developers taking shortcuts in the way they release, update, or deprecate APIs. The process of creating an API tends to require more technical savvy than merely ordering a cloud service.
Case Studies: Vulnerable in the Dark
The security community has been alarmed by these potential vulnerabilities. The OWASP Top 10 API security risk characterizes shadow APIs as API9:2019 Improper Assets Management. These kinds of risks can be exploited via a variety of crafty attacks.
This was the case with one Facebook password update service. When a user requested a password update, a 10-digit code was sent to their cell phone number. Subsequently, the original team realized this was a security vulnerability: hackers could quickly test out every possible 6-digit combination. The team added rate-limiting logic to reset attempts that locked out a request after 10 failed attempts.
This change created a new problem. Some Facebook teams used elements of the original API to protect other services. Even though the original service was updated, the changes did not permeate to these other services. Thankfully, the vulnerability was discovered by a team of white hat cybersecurity researchers rather than black hat hackers. Modern application tools could probably have identified this problem sooner.
In another case, JustDial, a local search service based in India, left an old API running after implementing a new version. An attacker found the latest version of the API and experimented with replacing the version number. This gave direct access to the old API with fewer security safeguards and exposed personal identifiable information of over 100 million users including usernames, emails, phone numbers, addresses, gender, date of birth, photos, and employment history. The API was left running for almost four years before being discovered by a security researcher.
Best Practices Light Up the Shadows
A number of best practices are available that enterprises can use to identify shadow APIs and mitigate their impact in the event one is compromised. Not only will these practices improve the security of your infrastructure but will make life easier for developers. These include:
Automate API documentation
The ideal scenario is to prevent APIs from falling into the shadows in the first place. Unfortunately, this is easier said than done. If developers are required to manually update the documentation at the end of each cycle, they may cut corners in a hurry. The best practice is to programmatically update the documentation with each change as part of an automated CI/CD build and deployment process.
Adopt API standards
Another good practice lies in developing a standard process for updating new APIs. The new OpenAPI Specification can help all stakeholders agree on exactly what an API is supposed to do before it is built. It defines a standard programming language description that allows humans and computers to understand what it does.
Inventory live APIs and document them
Unfortunately, improving API documentation is a bit like closing the barn door after the cattle have left. Teams should also programmatically survey what APIs are live, their endpoints, and their operations. Good API observability tools can help find these APIs and detect variance between what an API is supposed to do and what it does in practice.
Run security audits on deprecated APIs
The security team should run a comprehensive analysis of older versions of APIs when a new version is released. They can help assess current risks and decide whether it makes more sense to update old versions or terminate them completely.
Backport old APIs
A team may discover older APIs that are still being actively used by developers. It may be desirable to add security safeguards to this API with a minimal amount of change to how it behaves. Backporting is the process of weaving new security enhancements from newer versions of the API into the older version.
Patch CORS holes
Web security experts have long known about some of the challenges with cross-site scripting XSS attacks. Cross-Origin Resource Sharing is a modern variant in which one API is used to gain access to another. Modern API protection tools can minimize the blast radius if hackers manage to compromise one API in an attempt to access others.
Vigilance is the best Disinfectant
Every team should consider the possibility that shadow APIs may be living in the dark corners of their infrastructure. This is more likely the case if teams are not already proactively updating API documentation with each new release.
As shown with Facebook and JustDial, APIs can lay dormant for years until someone discovers them lurking in the corners. Those were discovered by white hat hackers through observant exploration with the flashlight of a penetration test. Enterprises should consider using modern observability tools to cast their own floodlights and highlight all the shadows at once
About the Author
George Lawton is a technology writer and regular contributor to The Inside Trace.
