Zombies and Shadows – The Dark Side of APIs
Are zombies and shadows lurking in your environment? They sound like something from a horror movie, but for digital innovators, they are very real and scary. These undocumented application programming interfaces (APIs) are proof that in the land of software development, what you can’t see can hurt you.
APIs are the backbone of web communication today, and the result is an explosion of hidden shadow APIs and zombie APIs that are almost impossible to keep track of. Without a unique approach to API security management to hunt them down and restrain them, they can be developers’ and security teams’ worst nightmares.
Why Shadow and Zombie APIs Are Dangerous
So what are documented vs undocumented APIs and why is this aspect of API protection often overlooked? API documentation files, like RAML files, Swagger files, or OpenAPI files, describe what an API is, what it looks like, where it lives, and what parameters it has.
This information is extremely important for AppSec teams to create security controls that protect them. Each API should be properly documented and updated any time changes happen, which in coding and development is all the time. The number of APIs grows by the day, and APIs come in and out of use very often. They aren’t always updated, or even documented in the first place. It’s easy to see why communication gaps between development and security teams set the stage for serious API security vulnerabilities.
Let’s unmask the mystery behind these specific types of hidden APIs:
What are Shadow APIs
Shadow APIs: When developers build APIs, they don’t always inform the AppSec team and the interface goes live without documentation. The API could have been used in a proof of concept and was forgotten about when the project was fast-tracked to production. Or the API was quickly spun up to meet an urgent business need. These shadow APIs are built outside of official processes and governance controls and remain unprotected.
What are Zombie APIs
Zombie APIs: Sometimes an API is developed and deployed with an application, but it’s never actually used — it’s basically a useless functionality that is only serving to expand the attack surface. Other times, developers build a new version of the same API but don’t decommission it right away. Instead, the API runs with the older API as a backup in case any issues arise. Over time, more traffic is sent to the new one until the old one becomes unnecessary and defunct, but developers forget to decommission it.
APIs that are left unchecked and undocumented quickly turn into API sprawl, leaving the door wide open to API security threats, such as:
Compromise of authentication tokens or exploitation of implementation flaws, allowing attackers to assume other users’ identities.
Taking advantage of authorization validation flaws that lead to information exposure or manipulation.
Denial of service attacks through network bandwidth, CPU, memory, and storage authorization weaknesses.
These are just a few of the most common API threats from the OWASP API Security Project. Click here to see the full list of the Top 10 List of unique API vulnerabilities and security risks in application programming interfaces, and to understand the challenges in securing an API footprint, check out A Guide to Modern API Security, a helpful guide and checklist from Checkmarx.
Best Practices For Dealing With API Sprawl
So, what can be done to stop this invasion and secure the gates? The first step is implementing an API security testing methodology and strategy that accounts for all these hidden APIs. There are three overall ways to accomplish this:
Start with a clear and comprehensive API governance strategy that includes rules for when both internal and external APIs may be used by developers and what practices need to be followed. These governance policies should ensure proper documentation.
Additionally, it’s imperative to track API security vulnerability disclosures for any external APIs. Internal APIs require teams to identify weaknesses themselves because there are no disclosures by third parties about APIs developed in-house.
Finally, continuously monitor all APIs to detect usage anomalies that could signal abuse.
Unfortunately, even using all of the above is not a perfect solution for complete API threat protection. API vulnerability scanning tools in standard API security platforms don’t make the cut because they can’t find the APIs that cannot be seen. Most of those tools can only scan APIs with live traffic moving through them, which rules out any undocumented zombies and shadows that aren’t currently being used.
Benefits of Holistic API Threat Protection Strategy
So, what can be done to secure APIs? To prevent API attacks, organizations need a holistic API security strategy. The best API security vulnerability assessment methodology spans the entire API lifecycle and includes both scanning live traffic and accounting for undocumented APIs. It starts by “shifting left” and performing API vulnerability testing at the code creation stage at the beginning of the SCLC. This is when developers are actively working on their code before it goes into production. It’s much easier and cheaper to fix flaws at this stage.
For instance, in just one API vulnerability scanner session, the Checkmarx One API security platform analyzes source code, open source dependencies, IaC templates and APIs. Then it aggregates, correlates, and verifies the results, and augments them with expert remediation advice. Shifting left allows organizations to discover and inventory all the API endpoints defined in the application source code. These tools are easily integrated with WAFs and API gateways to ensure complete visibility into the organization’s entire API landscape, protecting what’s not immediately obvious.
(Learn more about Checkmarx API Security’s unique approach to API security and see how a shift-left approach can help secure shadow and zombie APIs.)
The Obvious Solution
The growth of APIs in digital business is creating one of the biggest security headaches and challenges for organizations today. It is overwhelming to track, properly document, and even find hidden APIs. Relying solely on traditional runtime protection mechanisms and integrated controls post-production is ineffective as API use continues to increase, and protocols continue to evolve. The key is expanding the API security solution beyond just those devices that scan APIs for vulnerabilities using live traffic — in other words, “shifting left.” The Checkmarx API Security platform is a new and innovative way of securing APIs holistically from the entire SDLC. Go to Checkmarx API Security, and find out how to completely secure APIs, even those from attackers.
