What is Improper Assets Management (Shadow APIs)? Ways to Exploit, Examples and Impact

Master the risks of Improper Assets Management and Shadow APIs. Learn how attackers exploit undocumented endpoints and how to protect your infrastructure.

What is Improper Assets Management (Shadow APIs)? Ways to Exploit, Examples and Impact

In the modern era of rapid software development, organizations are deploying features faster than ever before. However, this speed often comes at a cost: visibility. As infrastructure scales across multiple clouds and microservices, it is common for security teams to lose track of exactly what is exposed to the internet. This phenomenon, known as Improper Assets Management—specifically involving Shadow APIs—has become one of the most significant risks in cybersecurity. In this guide, we will explore what these assets are, how attackers find them, and how you can secure your environment.

Understanding Improper Assets Management

Improper Assets Management occurs when an organization fails to maintain an accurate, up-to-date inventory of its digital assets. In the context of web applications and infrastructure, these assets include hosts, subdomains, APIs, and third-party integrations. When security teams do not know an asset exists, they cannot protect it, monitor it for vulnerabilities, or apply security patches.

This issue is so prevalent that it is officially recognized by OWASP. In the OWASP API Security Top 10, "Improper Assets Management" (API9:2023) highlights the risks associated with running multiple versions of APIs, forgotten staging environments, and undocumented endpoints. Without a centralized view of the attack surface, organizations leave doors wide open for attackers to exploit legacy bugs or unauthenticated interfaces.

What are Shadow APIs?

Shadow APIs are a subset of improper asset management. They are API endpoints that exist within an organization's infrastructure but are not documented, managed, or monitored by the IT or security departments. These often arise when developers create "quick fixes," testing endpoints, or internal tools that are accidentally exposed to the public internet.

To understand the scope of the problem, we must categorize these unmanaged assets into three main types:

1. Shadow APIs

These are entirely undocumented APIs created without the knowledge of the security team. They might be used for mobile app backends or internal data synchronization but lack the standard security controls like rate limiting or OAuth authentication.

2. Zombie APIs

Zombie APIs are older versions of an API (e.g., v1 or v2) that were supposed to be retired but remain active. While the current version (v3) might be secure, the zombie version often contains old vulnerabilities or lacks modern security headers.

3. Orphaned APIs

These are APIs that no longer have a clear owner or purpose within the organization. They might have been part of a project that was cancelled, yet the server remains running, consuming resources and providing a potential entry point for hackers.

Why Improper Assets Management Happens

Several factors contribute to the growth of an unmanaged attack surface:

  • Agile Development and CI/CD: Continuous integration and deployment mean code is pushed daily. Sometimes, temporary "beta" or "dev" environments are spun up and never torn down.
  • Microservices Architecture: Splitting a monolith into hundreds of microservices makes it difficult to track every single endpoint and its versioning.
  • Mergers and Acquisitions: When one company buys another, they inherit a massive amount of infrastructure that is often poorly documented.
  • Lack of Inventory Tools: Relying on manual spreadsheets to track assets is a recipe for disaster. Without automated tools like Jsmon, assets will inevitably slip through the cracks.

How Attackers Discover Shadow APIs

Attackers do not start by attacking your main login page; they look for the "low-hanging fruit" in your unmanaged assets. Here is how the reconnaissance process usually works:

Subdomain Enumeration

Attackers use tools to find all subdomains associated with a brand. A developer might have created api-test-internal.example.com thinking it was private. Tools like subfinder or amass can reveal these in seconds.

# Example of using subfinder to find hidden assets
subfinder -d example.com -all -silent

Directory and Path Brute-Forcing

Once a host is identified, attackers use wordlists to find hidden API paths. They look for common patterns like /api/v1/, /dev/, /backup/, or /swagger.json.

# Using ffuf to find hidden API versions
ffuf -u https://api.example.com/FUZZ/users -w versions_wordlist.txt

If the wordlist contains v1, v2, and old, and the server responds with a 200 OK for v1 while the documentation only mentions v3, the attacker has found a Zombie API.

Analyzing JavaScript Files

Modern web applications leak a lot of information in their frontend JavaScript. By crawling .js files, an attacker can find hardcoded API endpoints that were never meant to be public.

Technical Exploitation Scenarios

Scenario 1: Version Rollback Attack

Imagine a fintech company that updated its API to v2 to fix a critical Broken Object Level Authorization (BOLA) vulnerability. However, they forgot to disable the v1 endpoint. An attacker can simply change the URL in their request to target the older, vulnerable version.

Request to Secure v2:

GET /api/v2/accounts/5521 HTTP/1.1
Host: api.bank.com
Authorization: Bearer <token>

# Response: 403 Forbidden (User cannot access other accounts)

Request to Shadow v1:

GET /api/v1/accounts/5521 HTTP/1.1
Host: api.bank.com
Authorization: Bearer <token>

# Response: 200 OK (Data leaked because v1 lacks authorization checks)

Scenario 2: The Unprotected "Dev" Endpoint

Developers often disable authentication on development or staging environments to make testing easier. If dev.api.example.com is accessible over the internet, an attacker can access sensitive data without any credentials.

# Attacker finds a dev endpoint that returns all users
curl -X GET https://dev.api.example.com/debug/all-users

If this returns a JSON list of users, the organization has suffered a data breach due to improper asset management.

Scenario 3: Information Leakage via Swagger UI

Swagger (OpenAPI) is great for documentation, but it should never be exposed on production or unmanaged assets without protection. An attacker finding an exposed /swagger.json or /v2/api-docs can reconstruct the entire API structure, including hidden parameters.

The Impact of Improper Assets Management

The consequences of failing to manage your assets are severe:

  1. Data Breaches: Unauthorized access to PII (Personally Identifiable Information) through unauthenticated shadow endpoints.
  2. Compliance Violations: Regulations like GDPR, HIPAA, and PCI-DSS require organizations to know where their data is stored and how it is accessed. Shadow APIs bypass these audit trails.
  3. Reputational Damage: News of a breach involving "forgotten servers" makes a company look negligent.
  4. Resource Exhaustion: Zombie assets still consume cloud compute and database resources, leading to "cloud sprawl" and unnecessary costs.

How to Prevent and Mitigate Shadow API Risks

Securing your attack surface requires a mix of process changes and automated technology.

1. Implement a Robust Inventory Process

Every new API endpoint and version must be documented in a central registry. Use the OpenAPI Specification (Swagger) to define what your API does and who should have access to it.

2. Use an API Gateway

Force all API traffic through a centralized gateway (like Kong, Apigee, or AWS API Gateway). This allows you to enforce authentication, rate limiting, and logging across all versions. Any API call that doesn't go through the gateway should be blocked at the network level.

3. Automated Attack Surface Management

You cannot secure what you cannot see. Manual audits are outdated the moment they are finished. Use automated tools to continuously scan your infrastructure for new subdomains, open ports, and undocumented endpoints. Jsmon provides a powerful platform for tracking these changes in real-time, alerting you the moment a new asset appears.

4. Decommission Legacy Assets

Establish a clear "End of Life" (EOL) policy for API versions. Once a new version is stable, give users a deadline to migrate and then physically remove the old code and infrastructure. Don't just "stop using it"—delete the DNS records and shut down the containers.

5. Scan JavaScript for Hidden Endpoints

Integrate security scanning into your CI/CD pipeline to detect hardcoded URLs or sensitive API keys in your frontend code before it is deployed to production.

Conclusion

Improper Assets Management and Shadow APIs represent a silent threat that grows alongside your organization. As developers push for speed, the gap between what is documented and what is actually running in production often widens. By understanding the techniques attackers use to discover these hidden assets—from subdomain enumeration to version rollback attacks—you can take proactive steps to close those gaps.

Security is not just about building strong walls; it is about knowing exactly where every door and window is located. Regular audits, strict versioning policies, and automated discovery tools are essential components of a modern security posture.

To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.