Here’s a question I like to ask teams I work with: “Can you list every single API endpoint your company currently has running, in every environment, right now?” Almost nobody can answer that confidently. That gap — not knowing what you actually have exposed — is exactly what Improper Assets Management is about.
What Is Improper Assets Management?
Improper Assets Management (sometimes called Improper Inventory Management) happens when an organization loses track of its own APIs. This includes not knowing:
- Which versions of an API are currently live
- Which environments (dev, staging, production) are publicly reachable
- Which third-party or partner integrations still have active access
- Which old, deprecated, or “temporary” endpoints are still running
- What data each API exposes and to whom
The danger isn’t a coding flaw inside one endpoint — it’s that unmanaged, forgotten, or undocumented APIs often skip the security review, monitoring, and patching that the “official” APIs get. Attackers specifically look for these blind spots because they tend to have weaker defenses.
The Different Faces of This Problem
Let me expand this into specific sub-categories, because “asset management” covers a lot of ground.
1. Shadow APIs
APIs that exist and are running in production, but were never officially documented, approved, or tracked by the security or platform team. These often get created by individual developers or teams moving fast, without going through the usual review process.
2. Zombie APIs
Old API versions or endpoints that were supposed to be retired but were never actually shut down. The team moved on to v2, but v1 is still live, still reachable, and often still has the exact vulnerabilities that were fixed in the newer version.
3. Undocumented or Outdated Documentation
Even when APIs are known, the documentation might not reflect reality — missing endpoints, incorrect parameter descriptions, or outdated authentication requirements, making it hard for security teams to test the real attack surface.
4. Multiple API Versions Running Simultaneously
Organizations often keep v1, v2, and v3 of an API all live at once, for backward compatibility with older client apps. Each version might have different (and inconsistent) security controls.
5. Forgotten Staging/Test/Dev Environments
Non-production environments that were meant to be temporary but are still running, often with weaker security controls, sometimes still connected to real production data.
6. Third-Party and Partner API Integrations Without Oversight
APIs exposed specifically for partners or third-party services, where access might not be revoked promptly when a partnership ends, leaving a live, forgotten door open.
7. Internal APIs Exposed to the Public Internet
APIs meant only for internal microservice-to-microservice communication that end up accidentally exposed externally due to a misconfigured load balancer, gateway, or firewall rule.
8. Unmanaged API Keys and Credentials
Old API keys issued to former employees, deprecated integrations, or test scripts that were never revoked and can still authenticate successfully.
9. Multiple Teams Building Overlapping APIs Without Coordination
In large organizations, different teams sometimes build similar or duplicate APIs without realizing another team already has a properly secured, reviewed equivalent — leading to inconsistent security postures across the company.
10. Mergers and Acquisitions Leftovers
When companies merge or acquire other companies, old APIs from the acquired company’s systems often remain live and unmanaged long after the acquisition, sometimes forgotten entirely.
A Realistic Example
A company builds api.example.com/v1/payments for handling payments. A year later, they release v2 with stronger authentication and input validation, and update all official documentation and client apps to use it.
But nobody actually decommissions v1. It’s still running on the same server, still accepting requests, and still has the older, weaker security model. An attacker, scanning for common API version patterns, tries:
POST /v1/payments
…instead of /v2/payments, and finds it still works — with none of the newer protections. This is a textbook Zombie API scenario, and it happens constantly in real organizations.
Another scenario: a mobile app developer creates a quick internal testing endpoint:
GET /api/debug/user-dump?userId=123
…meant to be used only during development, then forgets to remove it before shipping to production. Nobody on the security team even knows this endpoint exists because it was never documented — a classic Shadow API.
Why This Happens
- Fast-paced development culture — moving quickly to ship features often means documentation and cleanup get deprioritized.
- Lack of centralized API governance — no single team or system tracks every API across the organization.
- No formal deprecation process — old endpoints are replaced but never properly shut down.
- Multiple teams and microservices — as organizations scale into microservice architectures, the number of APIs multiplies rapidly, making manual tracking impossible.
- Third-party integrations left unreviewed — access granted once and never revisited.
- Poor offboarding processes — API keys and credentials tied to former employees, contractors, or discontinued partnerships not being revoked.
How to Detect Improper Assets Management
- Perform API discovery scans using tools designed to find live endpoints across your infrastructure, rather than relying only on official documentation.
- Review DNS records, subdomains, and load balancer configurations for forgotten or unexpected API-related entries (like
api-staging.example.comorold-api.example.com). - Audit all API gateway configurations to list every route currently being proxied, and compare it against your official documented API list.
- Check version history in your API design — for every version bump, confirm whether the old version was actually decommissioned or just left running.
- Review third-party and partner access logs for API keys or tokens that haven’t been used recently but are still active, or ones tied to expired agreements.
- Search public code repositories and mobile app binaries for hardcoded API endpoints that might not be in your official inventory (developers sometimes leave old URLs in code comments or configuration files).
- Interview different engineering teams — sometimes the fastest way to find shadow APIs is simply asking each team what they’ve built and comparing notes against the central inventory.
How to Fix and Prevent This
1. Build and Maintain a Central API Inventory
Create a single source of truth listing every API, every version, every environment, and who owns it. This should be a living document/system, not a one-time exercise.
2. Implement API Governance Policies
Require every new API to be registered in the central inventory before it goes live, as part of the standard deployment process — not an optional afterthought.
3. Establish a Formal Deprecation and Retirement Process
When releasing a new API version, set a clear sunset date for the old version, communicate it to all consumers, and actually disable the old version on schedule — don’t let “just in case” thinking keep zombie APIs alive indefinitely.
4. Use API Gateways for Centralized Control
Route all API traffic through a managed gateway that gives you visibility into every endpoint being called, making shadow APIs much harder to hide.
5. Apply Consistent Security Standards Across All Versions and Environments
Every environment — dev, staging, production — and every API version should meet the same baseline security requirements. Don’t let “it’s just staging” become an excuse for weaker protection.
6. Regularly Audit Third-Party Access
Review all partner and third-party API integrations periodically, and immediately revoke access when a partnership or contract ends.
7. Automate API Discovery
Use continuous API discovery tools that scan your infrastructure regularly, so new or forgotten endpoints get flagged automatically rather than relying purely on manual documentation.
8. Tie API Ownership to Specific Teams
Every API should have a clearly identified owning team responsible for its security, documentation, and eventual retirement — “nobody owns it” is how zombie APIs are born.
9. Rotate and Revoke Unused Credentials
Regularly audit API keys and access tokens, and set expiration policies so unused credentials don’t remain valid indefinitely.
10. Document Thoroughly and Keep It Current
Treat documentation as part of the deliverable for any API change, not an optional extra step done “later.”
Business Impact
- Expanded attack surface — every forgotten API is a potential entry point that attackers can find even if your security team never reviewed it.
- Weaker protections on old versions — zombie APIs often lack fixes applied to newer versions, giving attackers an easy path around your improvements.
- Data exposure through forgotten integrations — old partner access left active can leak sensitive data long after a business relationship has ended.
- Compliance failures — regulators increasingly expect organizations to know exactly what data they expose and where; an incomplete inventory is itself a compliance risk.
Final Thoughts
Improper Assets Management isn’t about one broken endpoint — it’s about not knowing your own attack surface. You can’t secure what you don’t know exists. Building a habit of tracking, documenting, and properly retiring APIs is unglamorous work, but it consistently closes off some of the easiest wins attackers rely on.
