A single tool doesn't make an API secure. What actually works is the interplay of visibility, continuous testing, and enforcement, each stage covers a gap the others leave open.

1. CISpec diffing: new, unreviewed routes break the build
→
2. RuntimeDiscovery: real traffic checked against the approved spec
→
3. GatewayDefault deny: only approved paths, schema validated

Three layers, one goal: no endpoint in production that nobody knows about and nobody checks.

1. Know Your Inventory

Security begins with visibility. A protection measure, an authentication check, or a rate limit only works for endpoints the security team actually knows about. OWASP describes exactly this gap in the risk API9:2023 Improper Inventory Management: anyone running multiple API versions and environments needs not just a good understanding of their own APIs and endpoints, but also of how they share this data with third parties. Without that, OWASP says, a documentation blindspot and a data flow blindspot emerge.

The typical trigger is the silent drift between code and documentation. The OpenAPI specification describes the intended state at a given point in time, but the running service keeps evolving. Every hotfix, every new route, every forgotten deprecation plan widens the gap. This is exactly where three categories come in, ones that show up in real traffic but appear in no spec, ticket, or review:

  • Shadow APIs: according to Wallarm, undocumented endpoints that exist in the infrastructure without proper approval or oversight. Technically, a shadow API is an endpoint that shows up in actual traffic but isn't in the stored specification.
  • Zombie APIs: outdated, supposedly deprecated endpoints that everyone assumes are shut down but that keep running. OWASP cites as a scenario a beta host that runs the same logic as production but without the upstream rate limit, letting an attacker brute-force reset tokens.
  • Phantom and AI-generated endpoints: routes co-generated by code assistants or scaffolding tools that never went through a specification, ticket, or review. They make the drift worse, because code gets written faster than governance can track it.

This isn't a fringe issue. Salt Security reports in its State of API Security Report 2025 that 99 percent of organizations had API security problems in the past year, and for a quarter of respondents the API inventory grew by more than 100 percent within a year. At the same time, a third of respondents lack confidence in detecting AI-driven threats.

The core consequence: you can't trust documentation alone. OWASP recommends inventorying all API hosts and integrated services, including environment, access scope, version, and data flow, generating documentation automatically from open standards, and building it into the CI/CD pipeline. Just as important: no production data in non-production deployments, and protection measures for all exposed versions, not just the current production one.

The effective approach is continuous runtime discovery: you continuously compare real traffic against the stored specification. Wallarm defines shadow APIs as endpoints that appear in traffic but are missing from the spec, and zombie APIs via comparison of different spec versions. Detected deviations are flagged as a finding and can be reported directly to SIEM or SOAR. This turns the specification from a blindly trusted anchor into a continuously reconciled target-versus-actual instrument.

GET /users -> type_of_endpoint: shadow

  1. Finding: endpoint appears in live traffic but is missing from Specification-01.
  2. Consequence: no auth check, no rate limit, no monitoring applies.

Example of a discovery finding (per Wallarm): an endpoint observed in traffic that appears in no specification is automatically flagged as a shadow API.

2. Continuously Test the Right Things

The most common API risks aren't classic attacks with recognizable patterns, but logic and authorization errors. In Broken Object Level Authorization (BOLA, API1:2023), an attacker simply manipulates the ID of an object in the path, query, header, or payload. The request itself is technically completely legitimate. A signature- or pattern-based detector sees nothing unusual here, because the request matches the expected format exactly. What's violated is the rule that this user isn't allowed to see this object, and only the application itself knows that rule.

The same applies to Broken Function Level Authorization (BFLA, API5:2023): a regular user calls an administrative function, for example by switching the HTTP method (GET to DELETE) or by guessing an endpoint like /api/v1/users/export_all. These, too, are syntactically correct API calls. OWASP explicitly states that you can't infer from the URL path alone whether an endpoint is regular or administrative.

Why signatures aren't enough: BOLA and BFLA are context-dependent. Whether access is allowed follows from user identity, role, hierarchy, and object ownership, not from the shape of the request. That's why the right test has to be actively formulated:

  • Actively test, don't just detect: Can user A access user B's object? Can a normal user trigger an admin function? You have to deliberately play through such cases.
  • Default deny: for BFLA, OWASP recommends that the access logic deny everything by default and only explicitly grant it per role.
  • In-depth authorization analysis across roles, groups, and sub-users instead of spot checks.

Why yearly isn't enough: OWASP puts it unambiguously in its DevSecOps chapter: "Scanning and penetration testing yearly are no longer enough." APIs change with every deploy. An endpoint checked in January can have a new parameter, a new method, or a new role in February, and with that a new gap. A finding from twelve months ago says nothing about what's shipped today.

Shift left, tests in CI/CD: OWASP calls for continuous security testing across the entire software development life cycle and security automation in the pipeline, without slowing down development speed. Specifically, OWASP names as a prevention measure for BOLA: write tests that check authorization, and don't ship changes if those tests fail. That's exactly shift left: the authorization check becomes a quality gate in the deploy.

Reproducible findings with a record: OWASP emphasizes delivering findings promptly and in developers' own tools, not as a PDF, and making them tangible with a concrete attack scenario. A finding needs the exact request, the manipulated ID or method, and the observed response, so it stays reproducible and gets permanently locked down in a regression test.

Plus continuous runtime testing: pipeline tests check the known, declared state. The NIST publication SP 800-204D describes how security measures get integrated directly into the CI/CD phases build, test, package, and deploy. But because undocumented or outdated endpoints (OWASP API9:2023, Improper Inventory Management) slip through pure pipeline tests, ongoing monitoring in production is needed as a complement. Testing in CI/CD and runtime monitoring together cover both the planned and the actually exposed state.

BOLA scenario (from OWASP API1:2023): an e-commerce platform serves revenue charts via the endpoint /shops/{shopName}/revenue_data.json.

  1. The attacker reads the list of all shop names via a different endpoint and uses a script to substitute {shopName} one after another.
  2. Because the server doesn't check whether the logged-in user owns the shop, the attacker obtains the sales data of thousands of shops.
  3. The only protection: a test that actively plays through exactly this cross-tenant access and blocks the deploy if it succeeds.

BOLA in practice: a technically legitimate request that only a logic-based test recognizes as a violation

3. Enforce at the Gateway

The API gateway is the central point where cross-cutting policies are defined once and enforced for all downstream services, instead of repeating them in every microservice. Typical gateway functions are authentication and authorization, rate limiting against unbounded resource consumption, schema validation, and mTLS between components. Kong, for example, implements these functions as plugins bound per service or route, including a dedicated rate-limiting plugin.

The decisive principle is default deny: paths that aren't explicitly approved get rejected, not silently passed through. This aligns with Zero Trust per NIST SP 800-207, where no implicit access is granted purely based on network location; instead, authentication and authorization are decided as standalone functions before every access, based on identity and policy. CISA introduces Zero Trust via a maturity model with five pillars and three cross-cutting capabilities that leads step by step from static to dynamic, context-based decisions.

Important limit: a gateway only protects known routes. If an old API version, a test endpoint, or a shadow endpoint isn't registered at the gateway, no policy applies to it either. This is exactly what OWASP describes as API9:2023 Improper Inventory Management: old, unpatched versions and undocumented hosts enlarge the attack surface, are discoverable via Google dorking or DNS enumeration, and bypass the central controls. Discovery (a complete, current inventory of all endpoints) is therefore a prerequisite for any gateway enforcement.

A multi-layered pipeline closes the gap between spec and reality:

  • CI layer (spec diffing): every change is checked against the approved OpenAPI spec. New, unreviewed routes fail the build before they're shipped. This addresses OWASP API9 (current documentation, a retirement plan per version) and API8:2023 Security Misconfiguration.
  • Runtime layer: actual traffic is reconciled against the approved spec. Paths that respond but aren't specified (shadow or zombie APIs) trigger an alert. This feeds the inventory with findings that static reviews miss.
  • Gateway layer: default deny, schema validation, and gateway-side auth enforce the approved spec in the data path. Whatever isn't in the spec gets rejected.

The three layers interlock: CI prevents undocumented routes from arising; runtime catches what shows up anyway; the gateway enforces default deny. This way, coverage of OWASP Top 10 risks like Broken Authentication (API2), Broken Function Level Authorization (API5), and Unrestricted Resource Consumption (API4) isn't just documented, it's technically enforced.

CI Gate (OpenAPI Diff)
CI gate: build fails if the traffic spec deviates from the approved OpenAPI
$ openapi-diff approved-spec.yaml ./build/generated-spec.yaml --fail-on-incompatible
ERROR: 2 undocumented routes found, not reviewed:
  + POST /internal/v1/users/{id}/impersonate
  + GET  /v0/legacy/export        (deprecated, no retirement plan)
Build aborted (exit 1) - route not approved at the gateway -> default deny

Example CI spec diffing: unreviewed or outdated routes break the build before they get approved at the gateway.

More on the central enforcement layer: API Gateways. Why inventory is the prerequisite: Improper Inventory (API9).

Sources

Keep reading
EnforcementAPI Gateways RiskImproper Inventory (API9) WhyWhy API Security