Organizations are leveraging tens of thousands of APIs in their modern IT architectures. Developers use several APIs, including third-party ones, to build light, agile, responsive apps and websites. Though APIs are game changers for organizations, there is a growing shadow API problem.
Data suggests that 31% of malicious attacks target shadow APIs. In absolute numbers, that’s close to 5 billion out of 16.7 billion malicious requests targeting APIs in the shadows. So, shadow API is the biggest security risk facing organizations, leaving them vulnerable to a wide range of API security threats.
This article delves deep into what shadow APIs are, why they are a problem for organizations, and ways to protect yourself against them.
Shadow API: An Overview
In the simplest terms, an API living in the shadows you don’t track is what a shadow API is. A shadow API lives outside your organization’s defined IT governance, security processes, and peer review. These APIs are undocumented, untracked, unaccounted, and as a result, unmanaged and insecure.
Since these APIs aren’t authorized by the organization that owns the data/functions they offer access to, they are also known as rogue APIs. A shadow API may be developed in-house or a third-party API.
Shadow API gets its name from shadow IT, where apps are created and deployed, or public cloud instances are established outside the defined processes. Like shadow IT, shadow APIs are made and published outside the defined DevSecOps processes.
The owners of such APIs may be unaware of the publication process, or they may not be completely aware of the risks of publicly exposed APIs living in the shadows.
How would you track, monitor, govern, and secure something you don’t know exists? So, they remain so obscure and discreet that developers often don’t realize their presence. Unless an effective API security solution is used, shadow APIs may continue to lurk in the shadows for years.
What is the problem if APIs remain in the shadows? Well… attackers could find and exploit these vulnerable endpoints, blindsiding the organization completely.
Shadow API vs. Zombie API
At this point, we must point out that shadow and zombie APIs differ despite their many similarities. Zombie APIs are exposed APIs/ API endpoints that are outdated, abandoned, or forgotten. They were valid, approved, and served as a function earlier. But they have been replaced/updated with a newer version or simply abandoned now because they aren’t needed.
Since organizations are constantly on the go and looking to build the next piece of code or another new functionality, they lose focus on the older APIs. Sometimes, outdated APIs cannot be removed by organizations because of the following reasons:
- They support and help in integrating other apps
- They are used by partners in building their apps
- They are needed to support legacy versions of their apps/sites
- They may not know how the removal of the API may affect their performance and functioning
So, organizations don’t properly sunset or deprecate these APIs, which end up lingering and turning into zombie APIs.
Since these APIs are not removed and essentially forgotten by the organization, zombie APIs aren’t regularly patched, maintained, or updated on the functional or security front. The organization has several outdated, vulnerable endpoints that widen its attack surface. As a result, they become significant security risks for organizations, providing easy gateways for attackers to engage in various malicious activities.
On the other hand, Shadow APIs, also known as rogue APIs or shadow endpoints, are created and deployed without the knowledge or approval of an organization’s official API security, governance, and maintenance processes. These APIs exist outside the defined DevSecOps practices and are typically not visible to the organization’s authorized API management systems. Unlike zombie APIs that were once approved and valid, shadow APIs are unapproved and may not even be valid.
Overall, shadow APIs represent a potential risk to an organization’s overall API ecosystem, as they can bypass established security and governance controls, leading to potential issues with compliance, data integrity, and overall system stability.
Why do Shadow APIs Exist?
There are several reasons why a shadow API may exist or settle into the shadows of your IT infrastructure.
Developers rushed to complete a project and were created hurriedly by them without considering their governance and security processes or implications. For instance, developers may have used a third-party API or created an API outside the DevSecOps norms to resolve a problem instantly.
Or they may have leveraged an API developed as a proof of concept for a larger project without considering the defined policies and procedures. In either case, these APIs operate outside the organization’s security and operational processes.
Sometimes, a shadow API may have started as a fully managed API but copied as-is to support other apps/ services. They are used in these other apps/ services unmanaged, insecurely, and lurking in the shadows.
Sometimes, the organization may be unaware of the third-party API being used in a packaged application, a SaaS product, or the infrastructure components they are using. These APIs, too, need to be regularly updated, patched, and maintained. Unaware of their use/ existence, they live in the shadows and introduce security problems for the organization.
Another reason some APIs are left in the shadows because the organization leverages traditional security approaches and tools. These security tools and approaches are incapable of detecting these APIs. So, the organization is left with a widening attack surface.
Why is Shadow API a Problem?
At the very least, a shadow API leads to a governance issue. This typically happens when well-meaning developers violate privacy mandates or defined processes because they were unaware of them. Or they may be in a hurry to finish a project and leave the governance, security, and maintenance aspects for later.
But in worst-case scenarios, the consequences are more catastrophic.
- Attackers could create backdoors and steal valuable data, especially since these APIs are in the shadows and lack authentication, access controls, and encryption.
- Attackers may compromise apps/sites or spread malware using these APIs.
- Owing to a lack of visibility into the API and its assets, organizations have no idea who is accessing, using, or modifying the API, its data assets, functions, or the apps using them.
- Shadow APIs leave the organization vulnerable to OWASP Top 10 API security risks and other security threats.
- The app/website using shadow APIs has reliability issues. Attackers could leverage these APIs to cause downtimes, crashes, and unpredictable app performance. This leads to reputational damage, financial damage, and customer attrition.
- Being non-adherent to security and compliance best practices, the organization could face massive penalties if an API attack occurs.
- These APIs are unpredictable and increase operational costs for organizations.
Shadow API is such a big security risk and challenge that it is a vulnerability in API9:2023 Improper Inventory Management risk of the OWASP Top 10 API 2023 security risks.
The Facebook Example
Earlier, when a user wanted to update their Facebook password, they would make a request. And the Facebook Password Update Service would send them a numeric code on their mobile number.
The security team subsequently realized that this created a vulnerability allowing attackers to use brute force tools to test every possible code combination and crack the password. The team then set rate limits to lock out the user after ten failed reset attempts.
This change led to another new challenge for the platform’s security. Some of the Facebook teams leveraged the elements of the original API to protect the platform’s other services. Even though the actual service using the original API was updated, the changes didn’t permeate to the other APIs and services.
This created a shadow API vulnerability that attackers could exploit. A team of white hat testers identified this, and the problem was eventually remediated.
Shadow API Discovery: The Best Practices to Detect and Prevent APIs in the Shadows
The first and most important step to preventing and rectifying the shadow API problem is the effective discovery of all APIs. Below are ways to detect your shadow APIs:
1. Continuous API Discovery and Inventorying
Without this, you will most likely fall into the shadow API pit. You need a complete, continuously updated inventory of all your internal and third-party API endpoints. You need to know the dependencies, which apps and users are using, and calling the API. You need visibility into the API requests and responses throughout its lifecycle.
2. Consider Automation for API Documentation
Your API documentation needs to be updated regularly. But expecting developers to update it manually at the end of each cycle can lead to errors and waste time and effort. It is a best practice to use automation to update your API documentation after each change programmatically.
3. Develop Standard Procedures and Processes
You must adequately define and maintain standard procedures and processes for API development, deployment, updates, management, and maintenance. You should have proper API governance and management policies for internal and external APIs.
4. Live Traffic Monitoring
By monitoring your traffic, you can inspect and analyse all API requests. This helps you to identify any new APIs that are added instantly, especially when you use automated tools. You can keep track of and categorize freshly added data.
You can look for app glitches, performance anomalies, and suspicious user behaviour without constantly running manual performance tests. You can immediately get down to remediating the issue. So, intelligent tools infuse agility and speed into the process while optimizing costs.
Live traffic monitoring is done using API gateways most often. They are preferred owing to the ease of deployment and use. They isolate any security gaps and concerns resulting in APIs in the shadows.
The challenge, however, is that not all traffic goes through the API gateway. So, the visibility offered by an API Gateway is limited. Secondly, if shadow APIs exist in legacy apps that don’t receive updates, the chances of finding them using monitoring tools are slim.
Discover authorization, rate limits, and other ways to protect your APIs.
5. Outbound API Proxies
Outbound API proxies intercept and decode all outbound API calls, redirecting them to their proxy service. In doing so, they automatically log all API requests and responses while cataloging the API itself. Without time and effort, developers and organizations can understand what APIs exist, which apps/ sites are using which APIs, and the overall performance of APIs.
The main drawback of outbound proxies is that they require all traffic to pass through the proxy APIs. So, you are adding another point of failure in the process, which may impact the performance and reliability of your service.
6. API Marketplaces/ Trading Platforms
Trading platforms/ API marketplaces are similar to outbound proxies. The sole difference is that developers use the trading platform’s API client and act as intermediaries. The benefits and drawbacks are the same as outbound proxies.
7. Log Review and Analysis
Another effective way to detect a shadow API is by analysing and reviewing real-time application logs. These logs give you real-time visibility into API usage, freshly developed endpoints, response data, and other API metrics. You can detect API issues in real-time and deploy remedial solutions.
One of the main drawbacks of this approach is that log analysis demands huge log data storage space, thus increasing storage costs. To be effective, you must maintain complete logs, including payload information. Maintaining such ample storage also increases processing costs.
It also leaves your sensitive data open to the risk of exposure. If the logging tool is not configured correctly, it will either miss valuable information or provide too much.
8. Static Code Analysis
Static code analysis or scanning lets you track and map app source code to API usage. Unlike live monitoring, it is a non-invasive technique that does not run in your live application. It detects APIs even before they go into production. Without tedious integration at different stages, it holistically gives you automated data flow maps, telling where APIs are used and ensuring compliance.
The main drawback of this approach is that it is complex, making it hard to build. It will not be helpful unless compatible with all programming languages used in every stack. It also does not detect any performance issues with the APIs.
9. Perform Security Audits and Tests Regularly
You must perform regular security audits and manual testing to detect errors, new APIs, legacy APIs, API vulnerabilities, etc. Apart from being an essential compliance requirement, it also throws light on everything all stakeholders need to know about APIs. You can proactively understand and monitor current API risks.
Using security audits and test reports, you can streamline your API policies. You can also use the findings to discuss if certain legacy APIs are necessary and if they can be retired.
Enhance your API security audits with our practical API penetration testing checklist [Free Excel File]
The Way Forward
Shadow APIs have catastrophic consequences. Leverage a fully managed, holistic, API-specific security solution like AppTrana to avoid the shadow API problem.
