API Exposure: Why It’s Different from Traditional API Security

TL;DR

• Application programming interface (API) security protects the endpoints you know about, while API exposure measures what an attacker can actually reach, including unrecorded routes.
• In Salt Labs’ Q1 2025 State of API Security survey, only 15% of respondents were strongly confident their API inventories were accurate.
• Traditional security controls are capped by inventory accuracy, meaning unlisted endpoints miss protection, testing, and governance simultaneously.
• Shadow APIs, zombie APIs, and agent-generated APIs continuously cause inventory drift across dynamic cloud environments.
• Traffic monitoring only sees endpoints that have been called, leaving dormant but exposed endpoints completely invisible.
• Code analysis detects endpoints before they are deployed, allowing teams to attach ownership and commit history directly at the source.
• Effective visibility requires tracking reachability, downstream data access, and infrastructure permissions from an attacker’s perspective.

API Exposure: You Cannot Secure What the Inventory Never Listed

The fundamental gap in modern application programming interface (API) security is the delta between the documented API estate and the reachable one. API gateways record only the endpoints explicitly routed through them. OpenAPI specifications and code annotations reflect only what developers documented during active feature sprints. Neither mechanism captures what a service actually serves across dynamic, multi-cloud runtime environments.

The security consequence is immediate and compounding:

• Scope Exclusion: Security controls, web application firewalls (WAFs), and API gateways are applied exclusively to known, inventoried endpoints.
• Testing Deficits: Dynamic application security testing (DAST) tools and API scanners construct test suites around declared schemas, leaving unlisted endpoints completely out of scope.
• Flawed Governance: Executive risk reporting and compliance frameworks measure defense readiness against a fraction of the actual attack surface.

When an endpoint is missing from the central inventory, it is automatically omitted from protection, testing, and governance simultaneously. This exposure is formally categorized under OWASP API9:2023 Improper Inventory Management. OWASP explicitly identifies outdated documentation, no retirement plan for each API version, and a missing or outdated host inventory as conditions that leave unpatched API versions running and leaking sensitive data.

API Security vs. API Exposure: What Is the Difference?

API security is the practice of protecting known endpoints through authentication, authorization, rate limiting, schema validation, and vulnerability testing. API exposure is the measure of whether an endpoint can be reached from an attacker’s position and what access or data it grants once reached, regardless of whether it was ever documented.

API security controls are strictly scoped by the inventory, meaning their coverage ceiling is capped by the inventory’s accuracy. API exposure, conversely, is a structural property of the running system and does not consult the inventory at all.

An API exposure and vulnerability risk assessment requires evaluating three distinct operational components:

1. API Entry Point: The exact network path and entry conditions required for an actor (whether external, unauthenticated, or laterally positioned) to touch the endpoint.
2. Execution Path: The backend services, database operations, or secondary workflows that execution of the endpoint can initiate.
3. Business Impact: The sensitive data objects, internal metadata, or elevated administrative privileges returned in the HTTP response body or headers.

What Are Shadow, Zombie, and Agent-Generated APIs?

Only 15% of respondents to Salt Labs’ Q1 2025 State of API Security survey expressed strong confidence in the accuracy of their API inventories. Inventory drift occurs across three distinct failure classes, each driven by a different architectural mechanism:

1. Shadow APIs: Endpoints deployed directly to production environments by engineering teams without ever being registered in the API gateway, OpenAPI specification, or service mesh registry.
2. Zombie APIs: Legacy endpoints that were documented during active use and later deprecated or superseded, yet remain active in running code and continue serving requests without security monitoring.
3. Agent-Generated APIs: A term OX Security uses for endpoints that AI coding tools write and merge into main branches during routine development without a human logging or otherwise being cognizant of the fact that a new interface was added. Unlike a shadow API, no person decided to create it.

Agent-generated endpoints represent the newest and least visible class of inventory failure. Because AI tools generate code directly within pull requests, these endpoints can bypass design reviews, architecture tickets, and manual specification updates, which leaves the code itself as the first place the interface is recorded anywhere. The earliest point of control is therefore the coding agent, where OX VibeSec embeds security context as code is generated.

For a deeper examination of legacy and unrouted endpoint risks, see the deep dive on Shadow and Zombie APIs.

Traffic-Based vs. Code-Based API Discovery

Dimension	Traffic-Based Discovery	Code-Based Discovery
What it observes	Network packets, gateway logs, and active HTTP requests	Source code, abstract syntax trees (ASTs), routes, and infrastructure-as-code
What it can find	Endpoints actively receiving traffic	Endpoints written in code and configuration
What it structurally cannot find	Uncalled endpoints, dormant routes, and unrouted paths	Active execution state and actual network flow
First lifecycle visibility	Production deployment (upon first request)	Pull request / commit time
Uncalled endpoint reporting	Invisible / unreported	Discovered and mapped
Deployment requirements	Agents, eBPF probes, or gateway sidecars	Repository access and continuous integration and continuous delivery (CI/CD) integration

This comparison highlights a critical operational asymmetry: traffic-based discovery sees what was used, rendering an uncalled endpoint invisible regardless of how exposed it is; code-based discovery sees what was written, locating endpoints before they are ever reached without observing real-world usage.

Neither approach is complete in isolation. The structural gap between what is deployed in code and what is active in traffic is precisely where shadow, zombie, and unrouted APIs reside.

The Exposure Lifecycle

An endpoint’s exposure profile evolves across distinct stages of the software development lifecycle:

1. Written: Code exists in the developer workspace.
2. Merged: Code is integrated into the main repository branch.
3. Deployed: Code is compiled and running in the execution environment.
4. Called: Active traffic flows to the endpoint.
5. Documented: Schema is registered in an API specification or central inventory.
6. Superseded: A replacement endpoint is introduced.
7. Deprecated: Endpoint is marked for sunsetting, but remains running.
8. Decommissioned: Execution path is either fully removed or left running as a zombie API.

Crucially, an endpoint’s exposure shifts dramatically at two specific stages without any underlying code changes:

1. Routing and Gateway Configuration Changes: Modifying a reverse proxy, API gateway rule, or ingress controller can instantly expose an internal endpoint to the public internet.
2. Authentication and Permission Changes: Altering identity and access management (IAM) policies, JSON Web Token (JWT) validation scopes, or gateway authorizer settings can strip authentication controls from a live route.

Because neither shift leaves a footprint in the application source repository, a code scan alone will consistently miss these exposure changes. The probabilistic nature of cybersecurity dictates that any enterprise security platform worth considering absolutely has to transcend isolated tools’ data silos and be cognizant of a common context across your monitoring stack in order to provide security insight across all layers of your business activity.

What Does Complete API Visibility Require?

Achieving complete API visibility requires moving beyond single-source monitoring. Security teams must hold their visibility tooling to a rigorous, multi-dimensional standard:

• Dual-Source Discovery: Discovers endpoints directly from application source code as well as active network traffic.
• Endpoint-Centric Inventory: Keys records directly to individual endpoints rather than aggregating them broadly at the service or host level.
• Codebase Attribution: Traces every discovered route back to its exact repository, file path, and initiating commit.
• Data and Privilege Mapping: Identifies the sensitive data schemas, database tables, and IAM permission scopes each endpoint can reach.
• Dormancy Tracking: Maintains an accurate inventory of endpoints that exist in deployed code but have never been called in production traffic.
• Verifiable Retirement States: Tracks deprecation as an infrastructure-enforced fact rather than a passive documentation intention.

The formal artifact produced by meeting these criteria is an API Bill of Materials (API-BOM): a structured, machine-readable inventory of the API endpoints declared across an application’s source code, framework configurations, and OpenAPI files.

For a comprehensive breakdown of schema structures, generation pipelines, and governance integration, see the dedicated guide on the API-BOM.

Common Mistakes and Limitations

Organizations seeking to minimize their attack surface frequently fall into four common errors:

1. Treating the Gateway Catalog as the Inventory: Confusing routed traffic with total existence. A gateway catalog records only what has been explicitly routed, leaving unrouted internal endpoints and bypass paths entirely unmonitored.
2. Equating “Internal” with “Not Exposed”: Assuming that non-internet-facing routes carry no exposure risk. Internal reachability is the primary mechanism leveraged during lateral movement once a boundary perimeter is breached, and Model Context Protocol (MCP) connectors can be abused to reach internal endpoints through server-side request forgery.
3. Scoping Security Testing Exclusively to Documented Endpoints: Limiting penetration tests, DAST scans, and schema validations to the published OpenAPI spec. This guarantees that undocumented and shadow endpoints remain uninspected.
4. Deprecating in Documentation Without Decommissioning in Infrastructure: Marking an API as deprecated in developer portals or specifications while leaving the underlying service, pod routes, and database bindings active in production code.

The Limitation of Code-Based Discovery

While code-based discovery provides critical visibility prior to deployment, it carries a fundamental operational constraint: coverage is strictly bound to the specific programming languages, web frameworks, and router abstractions supported by the static analysis engine. If a microservice utilizes an unmapped framework or custom routing middleware, code-based discovery may fail to parse its routes. Coverage across your tech stack must be explicitly verified rather than assumed.

How OX Security Addresses API Exposure Management

Addressing API exposure requires extending the discovery axis into the source code where endpoints originate. OX Security’s API exposure management solution, built on the API Discovery capability in OX Code, starts discovery within the repository, mapping endpoints defined in application code or OpenAPI specifications back to the specific functions they execute and the repositories they inhabit.

This structural shift transforms how engineering and security teams remediate API risks:

• Direct Developer Attribution: An exposed endpoint is no longer flagged as an unanchored hostname or IP address; it arrives with the exact code location, commit history, and commit author attached.
• Code-Level Remediation: Fixes target the underlying source code, route definitions, and framework middleware rather than relying on ephemeral gateway patches or band-aid routing rules.
• Unified Security Context: API-level exposure findings correlate directly with application and cloud security context within a single console, rather than splitting them across AppSec, cloud engineering, and operations teams.
• Runtime and Cloud Context: Routing and authentication changes never reach the repository, so OX Cloud assesses reachability against the running environment, correlating the shared OX content lake with runtime events and mapping how an attacker could chain weaknesses from an entry point.

Closing the Inventory Gap

API security controls are fundamentally capped by the accuracy of the inventory you maintain, while API exposure operates without regard for what was documented. The critical operational question for engineering teams is not whether known endpoints have firewalls and authentication attached, but how undocumented, shadow, and zombie endpoints are discovered before an adversary reaches them.

Because exposure originates in the codebase and evolves across dynamic deployment paths, solving this challenge requires a code-centric discovery model. By continuously mapping endpoints from source to runtime, attributing ownership at commit time, and measuring reachability from the attacker’s perspective, organizations can close the blind spots an inventory leaves and secure their true attack surface.

To discover your organization’s total API exposure and bring complete visibility to your engineering stack, schedule a demo with an OX Security expert.