2023 OWASP API Security Top 10 Best Practices
After four long years since the original…
The phrase “shadow API” sounds mysterious, maybe even dangerous. In reality, shadow APIs are not the stuff of ghost stories or spy thrillers, but they can expose organizations to cyber risk and compliance problems. A shadow API is an application programming interface (API) that exists outside of normal controls and cyber defenses. Similar to the idea of shadow IT. For this reason, they can be attractive targets for malicious actors. This article explores the nature of shadow APIs and what can be done to prevent them from causing harm.
To understand shadow APIs, it’s useful to contrast them with their conventional cousins. An API should be known to the IT department that deployed it. It ought to be registered with an API management tool, governed by policies, and protected by security controls. Call these “normal APIs.” In contrast, a shadow API comes into existence outside of regular view—under the radar, so to speak.
There isn’t anything sinister going with a shadow API. Developers create them all the time for good reasons and with the best of intentions. For example, a developer might need an API for a project and quickly throw one together for a purpose that is known to the dev team, but no one else. The API might serve as a connector between two applications that lack “out of the box” APIs. The team is in a rush, so there’s no time to subject the API to any official governance procedures. It remains invisible to API management and security tools. It is in the shadows.
A shadow API can also be an API developed by a third party, such as a software-as-a-service (SaaS) vendor. It’s a regular API, in common use. However, if a team deploys it without including it in the organization’s API management system, it exists in the shadows. It’s out of sight and exposing the organization to risk.
A shadow API represents a point of vulnerability. It probably lacks the right authentication and access controls. It might expose sensitive data to unauthorized users, or even the general public. Hackers can also use the shadow API to gather information about an organization and plan their attacks accordingly. And, what is particularly problematic is that all this vulnerability is occurring completely out of view from security monitoring solutions. By the time anyone notices a problem, such as data exfiltration, a shadow API attack is probably well under way. Data breaches and system outages caused by shadow APIs are costly to handle. They can also lead to problems with regulatory compliance, e.g., with consumer privacy laws. Just think of the recent Optus breach in which a shadow API was exploited.
For some people, a shadow API is indistinguishable from a “zombie API,” but they are not the same thing. While both are ungoverned, unsecured, and invisible, the zombie API was once a normal API. It just got forgotten or was abandoned . For instance, if the obsolete version of an API, which got replaced by a new edition a few months ago, is still running, it’s a zombie API. This is more common than one might imagine.
Zombie APIs present a range of security and compliance risks. They are not patched, for instance. Nor are they monitored for suspicious activity.
Why make the distinction? The reason to differentiate shadow APIs from zombie APIs has to do with avoiding the situation in the first place. A shadow API comes into existence because someone wants it to be in existence. A zombie API exists due to neglect of API governance policies. Each problem requires a different solution.
Shadow APIs present a conundrum for API security managers. If they’re invisible, how does anyone even know to address their risk? The answer is that one should make an effort to discover them, so they will become visible. A number of techniques are proving effective at detecting shadow APIs. They include:
Each of these techniques requires the organization to maintain a complete inventory of APIs to compare with the results of log analysis, monitoring and so forth. Without such an inventory, no one would know if an API is supposed to be operating or not. An API management system is also necessary, because once the organization detects a shadow API, it needs a repeatable way to isolate it and apply controls to it—or take it down.
Noname Security can help with the detection of shadow APIs. The Noname API Security Discovery Platform automatically discovers APIs and creates a thorough API inventory. Discoverable targets include APIs based on HTTP, REST, GraphQL, SOAP, XML-RPC, JSON-RPC, and gRPC. The platform has flexible tagging capabilities, along with datatype assigning that groups APIs by application and business unit. It can also find exploitable intelligence about APIs, with the goal of understanding potential attack paths. From there, the platform can simulate attacker reconnaissance—rapidly finding and fixing API vulnerabilities. The platform does not require integrations, installations, or implementations.
A shadow API, which admins cannot see and is not subject to security controls or governance policy, is a source of risk. Hackers can exploit them to gain unauthorized access to sensitive information. Data breaches and compliance problems can result, among other negative outcomes. It is possible to detect shadow APIs, however, using techniques like log analysis and code scanning. Once discovered, a shadow API should be included in an organization’s central API inventory and be made subject to appropriate policies and controls.
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.