I’m often asked about shadow APIs and shadow API parameters—even by people with a lot of experience in the API development space. This isn’t terribly surprising, because shadow APIs aren’t typically a risk you would think about in the normal course of developing an API. In fact, some people are convinced that shadow APIs are really just a scare tactic used by security vendors to sell their tools.
However, in reality, shadow APIs are relatively easy to build and use. What’s the best way for us to understand them better? By looking at real-world examples! So that’s what we will cover in this post.
What are shadow APIs?
Let’s start with this example API request that I came across:
This is a request to a GraphQL API for generating the one-time password (OTP) used in authentication for a web service. You might not spot the issue if you’re not looking closely, so I marked it with a big red arrow. That otpDigit parameter is actually a major problem.
I discovered that this parameter is actually modifiable through the API. By modifying it, you can adjust the length of the one-time password required for authentication. What are the implications? I was able to change the value down to 1. This brought the number of possibilities for the password from a million to only 10!
Understandably, the development team was alarmed when I told them about this parameter, and they fixed it right away. Nonetheless, this is a perfect example of shadow APIs and their parameters. Most likely, this parameter was an initial developer convenience used for prototyping or testing. When the API went to production, support for the parameter was never removed, and it became a shadow API parameter.
Without someone probing this particular endpoint for what could be done with an undocumented parameter, this major vulnerability would not have been discovered. More importantly, a development team will not intently search for this until they’re presented with the vulnerability.
This example lays the groundwork for a working guideline regarding shadow API endpoints and parameters: Any of your API endpoints or parameters that aren’t directly in the spotlight of developer focus exist in the shadows, and they present a risk because the security team will likely overlook them, too.
What can I do about shadow APIs?
Now that you know what shadow API endpoints and parameters are, the follow-up question is what you can do about them. Obviously, you can’t just tell your security team to be more vigilant, especially regarding those things the developers aren’t even highlighting in their active work.
Most likely, you’ll need a tool or process to help you assess the security of your APIs. The type of tool you need depends on the size of your business and the number of APIs you have deployed. API Gateways or even API Security tools can get you a long way toward having the degree of security you need, but they may be more than you need. If you only have several endpoints available for API consumers, deploying a robust set of tools that track traffic across your stack and alert you to suspicious activity is definitely overkill.
A simpler approach is just to make sure your APIs are well-documented. This is also a great place to start. Begin by adopting the OpenAPI standard for documenting your APIs. Remember shadow APIs come into existence when you don’t pay attention to your endpoints and parameters. The entire point of the OpenAPI standard is to provide a model for you to specify—and therefore, know about—every endpoint and parameter across your API.
From there, you can also require your developers to provide this API documentation to the security team when deploying. The security team then tests the API against the documentation, to find any inaccuracies or gaps. This will prevent any blind spots.
Conclusion
Things won’t lurk in the shadows if you shine light into those spaces. At the end of the day, if you know the details of the APIs you’ve deployed, then shadow APIs can’t exist. While it’s perhaps not the most exciting task in the world, documenting your APIs will help to prevent opening up your APIs to malicious attackers.
Hopefully, this post has enlightened you about the definition and dangers of shadow APIs. Go shine a light on the shadowy corners of your API infrastructure to prevent security breaches!
Comments