Shadow APIs: The New Form of Shadow IT

Shadow APIs: The New Form of Shadow IT and What You Can Do About It

While many security professionals are more than familiar with the term “Shadow IT”, Shadow APIs are just starting to become a known phenomenon. 

And of course they’re becoming a big deal. Most organizations are beginning to feel the pain of the thousands of APIs in their companies – all running on multiple clouds, and growing each day. They simply don’t know how many APIs they have, where those APIs reside, and what those APIs are doing.

Shadow APIs make it worse. They are the unknown unknowns, and can be used to access sensitive information if left unchecked.

Consider this example from Facebook:

Facebook Authentication Bypass Using Shadow APIs

Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.

Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.

The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.

Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.

What is Shadow IT?

Shadow IT refers to the use of IT systems, devices, and software by employees within an organization without the knowledge or approval of the organization’s IT department. These systems and devices may be used to perform tasks that are outside the scope of the organization’s approved IT infrastructure, or they may be used to bypass IT controls or policies.

Shadow IT can present a number of risks to organizations. One risk is security vulnerabilities. When employees use unapproved systems or devices, the organization may not have visibility into the security measures in place to protect them. This can leave the organization vulnerable to cyber attacks, data breaches, and other security threats.

Another risk of shadow IT is data loss. If employees are using unapproved systems or devices, the organization may not have access to the data stored on them. This can make it difficult to recover important information in the event of a system failure or other unforeseen event.

In addition to security and data risks, shadow IT can also lead to compliance issues. Organizations are often subject to various regulations and standards that dictate how they can use and store data. If employees are using unapproved systems or devices, the organization may not be in compliance with these regulations and standards, which can result in fines, legal action, and damage to the organization’s reputation.

Managing and controlling shadow IT can be a challenge for organizations. It often operates outside the purview of the IT department, which makes it difficult to identify and track. Additionally, employees may be using shadow IT to perform tasks that the IT department is not aware of, which can make it difficult to understand the full extent of the problem.

To address shadow IT, organizations may need to implement policies and procedures to ensure that employees are using approved systems and devices. They may also need to educate employees about the risks of shadow IT and the importance of using approved systems and devices. In addition, organizations may need to invest in tools and technologies to help them monitor and manage the use of IT systems and devices within the organization. Overall, addressing shadow IT is essential for organizations to protect themselves from risks, ensure compliance, and maintain control over their IT infrastructure.

What are Shadow APIs?

A shadow API is one that lives outside the normal IT governance management and security processes. They are often undocumented, creating massive security and governance risks for organizations since teams lack visibility into how data and applications may be accessed by third parties.

At the very least a shadow API presents a governance issue, since well-meaning developers may violate local privacy mandates. In the worst cases, shadow APIs open a door for hackers to steal valuable data or compromise enterprise applications. 

There are many ways that APIs can settle into the dark corners of your IT infrastructure. They could have been deliberately created by developers rushing to get a new project finished. Shadow APIs also include zombie APIs that may have been deliberately or accidentally left running at the end of useful life.

Sometimes shadow APIs started as fully managed APIs that were essentially copied over to support other services and used in an unmanaged way. One big concern is that attackers can gain access to these older API endpoints and request access to other services. This may also enable hackers to execute account takeovers through the older unpatched versions of APIs hiding in the shadows.

Security experts have also raised concerns recently about shadow AI, in which business users find innovative ways to weave enterprise data into best-of-breed artificial intelligence services. The concern is that business users are not security experts and the rise of tools that enable citizen developers and citizen integrators pose a potential security risk despite the best of intentions.

In general, shadow APIs tend to be the result of developers taking shortcuts in the way they release, update, or deprecated APIs. The process of creating an API tends to require more technical savvy than merely ordering a cloud service.

Best Practices to Prevent Shadow APIs

A number of best practices are available that enterprises can use to identify shadow APIs and mitigate their impact in the event one is compromised. Not only will these practices improve the security of your infrastructure but will make life easier for developers. 

These include:

Automated API Discovery and Security Posture Management

The only real way to get a handle on all APIs in your organization, is to implement continuous API inventory – a solution that is able to automatically discover and catalog ALL APIs, including the potential risks they pose to the organization.

Automate API documentation

‍The ideal scenario is to prevent APIs from falling into the shadows in the first place. Unfortunately, this is easier said than done. If developers are required to manually update the documentation at the end of each cycle, they may cut corners in a hurry. The best practice is to programmatically update the documentation with each change as part of an automated CI/CD  build and deployment process.

Adopt API standards

‍Another good practice lies in developing a standard process for updating new APIs. The new OpenAPI Specification can help all stakeholders agree on exactly what an API is supposed to do before it is built. It defines a standard programming language description that allows humans and computers to understand what it does.

Inventory live APIs and document them

‍Unfortunately, improving API documentation is a bit like closing the barn door after the cattle have left. Teams should also programmatically survey what APIs are live, their endpoints, and their operations. Good API observability tools can help find these APIs and detect variance between what an API is supposed to do and what it does in practice.

Run security audits on deprecated APIs

Security teams should run a comprehensive analysis of older versions of APIs when a new version is released. They can help assess current risks and decide whether it makes more sense to update old versions or terminate them completely.

Backport old APIs

‍A team may discover older APIs that are still being actively used by developers. It may be desirable to add security safeguards to this API with a minimal amount of change to how it behaves. Backporting is the process of weaving new security enhancements from newer versions of the API into the older version.

Patch CORS holes

‍Web security experts have long known about some of the challenges with cross-site scripting XSS attacks. Cross-Origin Resource Sharing is a modern variant in which one API is used to gain access to another. Modern API protection tools can minimize the blast radius if hackers manage to compromise one API in an attempt to access others.

About Traceable

Traceable is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire development lifecycle. Visual depictions provide insight into user and API behaviors to understand anomalies and block API attacks, enabling organizations to be more secure and resilient. Learn more at traceable.ai.