The Growing Problem of Shadow APIs

As the world becomes increasingly digital, organizations are making the transition from on-premises systems to cloud-based services. According to a report from McAfee, 97% of organizations worldwide are using some type of cloud service, making cloud adoption an essential aspect of modern business operations. With this rise in cloud adoption, there has been a corresponding increase in the use of APIs. APIs enable communication between different software applications and platforms, making them an integral component of the digital ecosystem.

However, this rapid adoption of cloud services and APIs has also led to the emergence of shadow APIs, which pose significant security risks for organizations. A study by Gartner suggests that by 2022, APIs will be the most common attack vector for data breaches, and shadow APIs are a significant part of this problem. Shadow APIs are essentially unknown, outdated, or undiscovered endpoint APIs that can leave an organization vulnerable to potential attacks.

The consequences of shadow APIs are evident in various real-world incidents. One such example is a data breach at Twitter, after exploiting an API vulnerability disclosed in December 2021. In another instance, the unintended reactivation of outdated code resulted in a massive financial loss for Knight Capital in 2012. These events underscore the serious risks and potential damage associated with shadow APIs.

Sources of Shadow APIs:

Business-related APIs:

Some commercial software packages include APIs to connect with other applications and external data sources. These APIs sometimes get activated without anyone noticing, potentially exposing the organization to security risks. For example, a cloud-based customer relationship management (CRM) system may include APIs to integrate with email marketing or e-commerce platforms, but if not properly secured or monitored, these APIs can become a vulnerability.

Outdated API versions:

In many cases, an older version of an API—possibly with weaker security or a known vulnerability—never gets removed. The old version may have to coexist with a new version for some time while software gets updated. But the person responsible for deactivating the API may leave the company, get reassigned, or simply forget to shut down the old version, leading to what is sometimes referred to as a zombie API. For instance, a widely-publicized Equifax data breach in 2017 was attributed to an unpatched vulnerability in an older version of the Apache Struts framework, which exposed sensitive information of millions of consumers.

Complex Manual discovery:

During a manual API audit, it may take up to 40 hours per API to record all the necessary inputs and make an exact list of them. However, the real time needed can vary by a lot. This difference is caused by things like the complexity of the API, the skill of the inspector, the audit method used, and the tools used. When automatic tools and methods are used, the time and work needed for API checks can be cut down by a lot. In some cases, a manual check may still be needed to make sure that a review is complete and correct. Once an API problem is found, it may take more time to look into it, figure out how bad it is, take corrective action, and figure out what caused it.

Reactivated Code:

In some cases, old code can be accidentally reactivated. This may occur when a software update or configuration change inadvertently activates dormant code, creating a potential security risk. A well-known example is the 2012 Knight Capital incident, where one of the eight trading servers ran an older software version that activated dormant test code. In just 45 minutes, the erroneous code executed 4 million stock trades, resulting in massive financial losses for the company.

Bypasses and procedural breakdowns:

Rogue APIs may result from failing to inform the right people or bypassing established procedures. For example, a line of business team might create APIs to address specific needs without informing the IT or security team, or developers may prioritize execution over procedure. These are often referred to as shadow APIs.

Inheritance:

APIs that have been “inherited” as part of mergers or acquisitions are also frequently overlooked and become shadow APIs. Inventories (if they exist) often become lost in the difficult and complicated work of integrating systems. Larger enterprises that make numerous acquisitions of smaller firms are especially at risk, as smaller firms’ API estates are often sprawling and undocumented.

Mitigating the Risks of Shadow APIs:

Organizations must take proactive measures to mitigate the risks associated with shadow APIs. The rise in cloud adoption and the use of APIs in modern business operations requires organizations to be vigilant about their API security. A failure to properly secure and monitor APIs can lead to significant security breaches and financial losses.

To address these risks, organizations can adopt best practices such as:

• Conducting regular API audits to identify shadow APIs and other potential vulnerabilities.
• Implementing robust API governance policies and procedures to ensure that APIs are properly managed and secured
• Using automated tools and methods to reduce the time and effort needed for API checks
• Establishing alignment between business teams, IT, and security teams to ensure that APIs are properly managed and secured

Learning more about mitigating the risks of shadow APIs and other API security best practices, leading people can join the upcoming “API Blind Spots Webinar: Discovering and Reducing the Risks of Shadow APIs.” The webinar will cover the causes and risks of shadow APIs and provide insights from industry experts on how to manage hidden vulnerabilities. Attendees will also have the opportunity to participate in a Q&A session with the panel of security experts.