What is an unmanaged API?
Unmanaged APIs are undocumented interfaces that operate outside standardized security and governance frameworks. These APIs include unsanctioned general use interfaces (e.g., payment gateways) and APIs used in runtime hosts, compilers, profilers, and debuggers to provide developers precise control over system performance. Unmanaged APIs bypass managed runtime security, obscuring security weaknesses while allowing direct interaction with (and attacks on) managed runtime components.
The result is an attack surface that threat actors can exploit, unchecked, to control sensitive assets. Your best bet for remediation? A centralized API catalog, powered by agentless cloud discovery and code-to-cloud correlation to ensure comprehensive API security.
Advanced API Security Best Practices [Cheat Sheet]
Download the Wiz API Security Best Practices Cheat Sheet and fortify your API infrastructure with proven, advanced techniques tailored for secure, high-performance API management.
Are unmanaged APIs the same as shadow APIs?
Shadow APIs are undocumented endpoints created without organizational knowledge or approval.
On the other hand, “unmanaged APIs” are a broad category. Referring to APIs that aren’t subject to management policies, unmanaged APIs can include shadow (unknown/undocumented) APIs, zombie (deprecated but still reachable) APIs, and orphaned/rogue APIs.
| Shadow APIs | Unmanaged APIs | |
|---|---|---|
| Description | APIs created without approval or monitoring | APIs operated outside centralized policy enforcement (API gateways, IAM, rate limiting), with or without approval |
| Technical use cases | Duplicate endpoints created to bypass release approval gates, security reviews, or rate limits | APIs created for handling low-level performance tracking, APIs powering debugging operations, or redundant and forgotten API instances |
| Discovery methods | Since shadow APIs communicate over HTTP/HTTPS like documented APIs, they're discoverable through network traffic analysis and cloud/infra scanning. | Unmanaged APIs that communicate through HTTP/HTTPS are discoverable through network traffic analysis and cloud/infra scanning. Debugging and profiler APIs require the analysis of build processes, code repos, and binary artifacts. |
Why unmanaged APIs create critical security risks
Unmanaged APIs allow developers to build, deploy, and debug features quickly and flexibly, without having to wait for approvals or integration. But in many cases, their risks far outstrip their benefits.
That’s because security controls for unmanaged APIs are implemented manually (and often inconsistently), introducing security vulnerabilities:
| Unmanaged API risk | Description | Example scenario |
|---|---|---|
| OWASP API1: Broken Object Level Authorization (BOLA) | Unmanaged APIs are rarely subjected to the same authorization checks as their managed counterparts, creating situations where the APIs don’t consistently limit who can access what data. | An unmanaged document-fetching API controls endpoint access using client-supplied IDs. Without tokens to verify object-level ownership and access rights, this vulnerability lets an attacker retrieve users’ sensitive documents by manipulating the document ID. |
| OWASP API 4: Unrestricted Resource Consumption | Unmanaged APIs bypass centralized rate limiting (quotas, throttling, timeout limits), making them vulnerable to DDoS attacks. | A dev ships a test pricing API to production without proper oversight. Because the API doesn’t have rate limits, attackers overwhelm backend databases and grind checkout to a halt. |
| OWASP API5: BFLA | Unmanaged APIs exist outside of centralized controls that enforce and verify whether or not users can access specific high-privilege functions. | An unmanaged profiling API with BFLA could let a user with unintended access to JVMTI (e.g., through misconfigured permissions or compromised credentials) invoke privileged functions or inject code into running processes. |
| OWASP API9: Improper Inventory Management | Since they’re deployed outside an organization’s documented API catalog, it’s impossible to enforce consistent security policies across unmanaged APIs. | An organization discovers they have a shadow API with access to a sensitive database only after attackers have exploited a BOLA vulnerability and stolen customer data. |
| Direct memory access–related vulnerabilities | When implemented in memory-unsafe languages (C, C++, assembly) and interacting directly with OS primitives, unmanaged profiler/debug APIs can bypass language-level memory safety guarantees provided by managed runtimes like the JVM or .NET CLR. | A pointer dereference issue/dangling pointer causes an app to crash by creating a mismatch between a direct pointer, the original object (which has been moved), and the new object now taking its place. |
| Unmediated control of managed runtime environment | Unmanaged profiler/debug APIs are directly accessible and have minimal (if any) abstraction from underlying code and infrastructure, which means a compromise will be especially devastating. | An attacker exploits a Windows debugger API to execute arbitrary code or hijack the system. |
| No safety nets | Because they exist within unmanaged code, some unmanaged APIs are deployed away from runtime protections like memory-safe languages (Go, Java), compiler hardening (ASLR, DEP), or kernel-level isolation (SELinux, AppArmor). | A legacy financial service API, written in C++ and compiled without Position Independent Executable (PIE) flags, runs on systems where ASLR isn't enforced. An attacker discovers a buffer overflow vulnerability. With the predictability of the memory layout, the attacker successfully executes a return-oriented programming (ROP) attack, injecting malicious code and completely bypassing the application's limited runtime security checks. |
| Governance and compliance risks | Hidden from governance systems, unmanaged APIs create unmonitored dataflows and violate regulatory frameworks like ISO 27001 and GDPR that require strict control and audits of customer information. | An application team launches an unmanaged logging API that captures and transmits PCI DSS–protected cardholder data to an unauthorized external analytics service. Because the API is unknown, this data flow remains unencrypted and unmonitored, resulting in a severe GDPR violation. |
How unmanaged APIs emerge in cloud environments
Rapid releases
Development velocity drives teams to prioritize functionality over security, especially when centralized governance or management-layer overhead affect release schedules or application performance. (Pro-tip: You can adopt a secure SDLC framework where centralized governance is implemented without slowing down development.)
Cloud complexity
Interfaces like the Spring Boot Actuator and cloud provider–managed metadata APIs—e.g., AWS and Azure Instance Metadata Services (IMDS), accessible from link-local 169.254.169.254—add to API management complexity. This complexity can lead to circumstances where misconfigurations turn APIs into unmanaged endpoints and attractive targets for attackers.
Specialized optimization and access requirements
In performance-critical applications like gaming backends and real-time financial systems, developers sometimes intentionally bypass the overhead from authentication middleware, API gateways, and managed runtime to deliver faster processing speeds and live debugging of unmanaged code. The same scenario occurs in the development of services such as debuggers, compilers, profilers, and runtime hosts, which require direct memory and application access for performance and integration.
Legacy platform integration
Integration points from legacy systems and their native interfaces/protocols (for instance, DCOM and CORBA) become unmanaged endpoints due to the complex workarounds needed to integrate them with modern API management frameworks.
With workarounds like wrappers and middleware rendering them invisible to central inventory and governance, the unmanaged APIs become huge security risks.
Watch 12-minute demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Watch now
Discovery approaches for unmanaged APIs
Effective API detection combines multiple discovery methods, including external attack surface mapping, cloud control-plane inventory, network telemetry, and runtime eBPF signals, into a unified graph of endpoints, identities, data, and exposures.
External attack surface mapping (EASM)
Using techniques like web crawling, EASM provides an “outside-in” view of publicly exposed APIs and other internet-facing assets. By showing businesses unmanaged APIs and the vulnerabilities in them from an attacker’s perspective, EASM lets security teams fix potential attack paths quickly to prevent breaches.
Cloud control-plane inventory
A cloud control-plane inventory acts as a central catalog, providing an “inside-out" view of runtime assets, including APIs. Through scans of cloud environments and configurations, the control plane continuously discovers and registers cloud-managed APIs (API gateway endpoints, Lambda function URLs, serverless HTTP triggers) and related identities/resources within the central inventory.
In other words, control planes collect schemas and usage patterns to identify and govern undocumented APIs.
Network telemetry: Load balancer/WAF/service mesh telemetry
Traffic analysis exports metadata like request paths/methods, source/destination ports, and response codes from load balancers, web application firewalls (WAFs), and service meshes.
Runtime eBPF signals
Monitoring solutions that are focused on finding unmanaged APIs through API gateways, WAF logs, and CI/CD scans still miss critical unmanaged APIs like service-to-service calls and unknown API listeners.
Runtime eBPF signals close the gap. They provide deep host-level visibility into process execution, network connections, and syscalls (and, when enriched with userspace probes, HTTP metadata), giving security teams visibility into traffic within hosts/machines to:
Spot internal unmanaged APIs
Flag APIs that are meant for internal use but are misconfigured to allow external access
Find redundant shadow API versions
Compare OpenAPI spec with runtime behavior to identify undocumented APIs/drift
Validate API runtime vulnerabilities with threat signals for proactive mitigation
How to govern and manage APIs effectively
To eliminate unmanaged APIs, here are a few essential tips:
Adopt API security and governance best practices and continuously assess your cloud environments for unknown risks.
Automate API discovery and inventory management by using tools that implement multiple discovery methods across the entire API lifecycle.
Adopt autonomous, centralized API governance by defining and enforcing governance policies, applying centralized IAM, and standardizing API lifecycle management.
Use secure managed instrumentation or eBPF-based runtime observability instead of unmanaged APIs in production environments.
Implement secure coding practices to safeguard your stack from the ground up.
Use firewall and network policy rules to explicitly allow required traffic and deny all else by default (default-deny), aligned with zero trust principles.
Implement continuous monitoring, e.g., track unusual calls to spot unmanaged APIs and associated malicious activities early.
Apply platform-specific controls. In AWS, this could look like enumerating with AWS SDKs and CLI, comparing findings with API docs, and cross-checking with AWS Config to spot drift or misconfigurations.
API security posture management explained
API security posture management, or API-SPM, is a security discipline that focuses on maintaining and proactively improving the security health of enterprise APIs.
Mehr lesenHow does Wiz's code-to-cloud approach effectively tackle unmanaged API risks?
When it comes to finding and addressing unmanaged APIs, Wiz raises the bar with a graph-based architecture that merges agentless discovery with runtime scanning, exposure mapping, code-to-cloud correlation, and a host of other frameworks. Here’s a closer look:
Wiz's agentless discovery capabilities and the Wiz Security Graph enable teams to quickly surface unmanaged APIs across multi-cloud environments, providing unified visibility at scale.
Wiz Code empowers developers to prevent unmanaged APIs from being introduced in the first place by embedding shift-left security directly in CI/CD pipelines.
Wiz correlates API risks with cloud context—linking internet exposure, IAM permissions, sensitive data access, and misconfigurations to unmanaged interfaces. This reveals real attack paths (e.g., exposed API → overprivileged role → customer database) for prioritized remediation.
Wiz’s seamless integration with existing DevSecOps workflows makes it easy to enforce policy, automate remediation, and continually reduce API risk without slowing down releases.
Start eliminating unmanaged APIs (and the risks they pose) today. Get a demo to see how Wiz does it best.
Agentless, contextual API discovery
Wiz helps teams quickly uncover every API in their cloud environment, known and unknown, and see their exposure with full execution context. This makes it simple to answer: What APIs do I have, and where are they running?
