APIClarity: Detecting Shadow APIs

Detecting Shadow APIs

In this blog, I’ll demonstrate how APIClarity detects and reports shadow APIs for an application. For review, a shadow API is an undocumented API that is accepted by an application and can present a potential attack vector. As mentioned previously, attacks via shadow APIs are on the rise. Therefore, detecting them and either properly documenting and securing them or shutting them down is increasingly important. 

Behind the Scenes 

Throughout the APIClarity blog series, we’ve been using Sock Shop as our sample microservice application. See the installation blog for specifics on setting up APIClarity with Sock Shop.

In order to illustrate APIClarity reporting a shadow API, I've uploaded an OpenAPI spec for the catalogue service, but this time I’ve removed one of the catalogue APIs from the spec before uploading it. The missing catalogue API endpoint is "/catalogue/{id}."  

Figure 1 shows the list of uploaded catalogue API endpoints for my setup.

Note that "/catalogue/{id}" is not in the list. Compare this to Figure 6 in the upload blog. When I generate traffic that uses this API, APIClarity will report it as a shadow API, because it is unknown in the uploaded OpenAPI spec. See the "Generate Traffic" section of the installation blog for details on how to generate traffic.

Detecting Shadows 

In order to detect shadow APIs, APIClarity first needs to know the list of acceptable APIs for an application. This can either be from an uploaded OpenAPI spec, or a reconstructed one. 

After an OpenAPI spec is approved, APIClarity will compare incoming API requests against it. If any API requests are for an unknown endpoint, they will be reported as shadow APIs.  

APIClarity displays this symbol for shadow APIs:

Shadow APIs will be reported on the APIClarity dashboard UI (if they happened recently), or from the API Events UI.  Below is an example of a shadow API being reported on the dashboard (circled in green in Figure 2). 

And this is an example API event being reported as a shadow API (circled in green in Figure 3). 

Bringing Shadows into the Light 

If an API that is considered a shadow API by APIClarity is actually expected, you can “legitimize” the API by either uploading an OpenAPI spec that includes that API endpoint, or by accepting the reconstructed spec that includes it. Note that any API calls that occurred before the API became legitimate will still be marked as shadows in the event list. 

Conclusion 

We’ve now seen how to detect shadow APIs with APIClarity, and how to mark those APIs as legitimate if needed.  

Next up in the blog series, we’ll take a look at using APIClarity to detect zombie APIs! 

---

Anne McCormick is a cloud architect and open-source advocate in Cisco’s Emerging Technology & Incubation organization.