API security vulnerabilities expose the enterprise’s hidden attack surface

At a glance

What this is: API security vulnerabilities are framed as an unmanaged attack surface created by incomplete inventory, broken authorization, and scanner blind spots across distributed endpoints.

Why it matters: IAM and AppSec teams need endpoint-level ownership and access governance because API risk is driven by who can reach what, not just by whether a scanner found a flaw.

By the numbers:

• Akamai’s 2026 data shows unauthorized workflows and abnormal behavior accounted for 61% of all API attacks in 2025, up from 30% the year before.
• Customers using ArmorCode to run correlated remediation reported remediation accelerated by up to 97% and alert volume cut by up to 90%.

Context

API security is the governance problem created when application connectivity expands faster than ownership, inventory, and authorization controls. In distributed architectures, endpoints become the real perimeter, yet many security programmes still measure only web applications and network boundaries.

For identity and access teams, the key issue is not just finding APIs but understanding who can invoke them, which objects they can reach, and which routes bypass central policy enforcement. That makes API security a practical intersection of access control, application security, and workload governance.

Key questions

Q: What breaks when APIs are not inventoried and monitored properly?

A: Uninventoried APIs become shadow trust surfaces. Teams lose visibility into who can call them, whether they are still needed, and whether their permissions have drifted. Without logging and inventory, security teams cannot prove access legitimacy, investigate abuse, or remove stale paths before attackers or automation discover them.

Q: Why do broken object and function authorisation keep causing API breaches?

A: Because the application often checks identity at login but fails to bind that identity to the object or action being requested at runtime. Attackers can change object identifiers, call hidden routes directly, or repeat privileged requests from an authenticated session. The failure is server-side authorisation, not user-interface masking.

Q: How do teams know if API security testing is actually effective?

A: Look for coverage of realistic workflows, successful reuse of returned values, and findings that map to business operations instead of only parameter errors. If a tool cannot move from one response to the next with meaningful context, it is probably testing syntax, not logic.

Q: How should organisations align IAM with API security governance?

A: They should treat APIs as access paths that carry identity, privilege, and lifecycle obligations. That means service accounts, OAuth applications, and workload tokens need the same ownership, scope review, and retirement discipline that human accounts receive. Without that alignment, API security remains fragmented across teams.

Technical breakdown

Why API inventory gaps create hidden attack surface

APIs are often deployed as routes, service calls, or serverless functions that never pass through a single authoritative registry. Shadow APIs appear when teams ship endpoints without security review, while zombie APIs persist after deprecation and remain reachable in production. Traditional CMDBs, gateway logs, and perimeter scanners each see only part of the picture, so discovery has to combine telemetry from ingress, runtime traffic, and source repositories. The technical problem is not merely missing documentation. It is that the organisation cannot assert which endpoints exist, where they sit in the request path, or whether they are still intended to be callable.

Practical implication: build continuous API discovery from logs, traffic, and code, or inventory blind spots will keep defeating downstream controls.

How BOLA and BFLA turn access checks into exploit paths

Broken Object Level Authorization happens when an endpoint accepts an object reference but does not verify that the caller owns that object. Broken Function Level Authorization happens when privileged actions are reachable by users who should only see them in a user interface. Both failures are identity and authorization problems, not syntax problems. The request may be perfectly formed and the code may behave exactly as written, yet the application still hands out another user’s record or executes an administrative action. This is why API risk sits squarely inside access governance, not just vulnerability scanning.

Practical implication: test object ownership and server-side role enforcement at every endpoint, not just whether authentication is present.

Why traditional SAST, SCA, and DAST miss API logic flaws

SAST can find bad patterns in source code, but it struggles when authorization is split across services. SCA can identify vulnerable dependencies, but it cannot judge whether a custom route leaks objects or privileges. Traditional DAST crawlers were built for pages, forms, and browser sessions, so they miss stateless JSON workflows and multi-step API sequences unless they are made schema-aware. The result is a tooling mismatch: the controls that work well for web interfaces do not automatically understand decoupled service-to-service interactions. API testing therefore requires contract validation, fuzzing, and workflow-aware dynamic checks.

Practical implication: use API-specific testing alongside existing AppSec tools, or the highest-risk failures will remain invisible until production abuse.

Threat narrative

Attacker objective: The attacker wants to use overlooked API routes and weak authorization to reach data, actions, or workflows that should never be exposed to their account.

1. Entry occurs through shadow, zombie, or poorly governed API routes that are reachable even though they were never fully inventoried.
2. Credential or request abuse follows when an attacker uses a valid session or direct request to probe object identifiers, privileged routes, or weak token checks.
3. Escalation and collection happen when broken authorization exposes other users’ records, administrative actions, or sensitive workflow data across decoupled services.
4. Impact is business-level exposure, including unauthorized data access, abusive workflows, and cloud cost or operational disruption through over-permissive API behavior.

Breaches seen in the wild

• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API inventory debt is now a governance failure, not a tooling gap. When an organisation cannot enumerate its endpoints, it cannot assign ownership, enforce policy, or prove scope. That creates hidden routes that bypass the same controls teams rely on for web applications. Practitioners should treat discovery as a continuous control, not a one-time scan.

API authorization belongs in the identity control plane. BOLA and BFLA are not exotic vulnerability classes. They are evidence that object ownership and function entitlement were never enforced where the request is executed. That means IAM and AppSec teams need a shared model for server-side access decisions, especially in microservice and partner-facing environments.

API risk now looks like access governance plus workflow abuse. The highest-value attacks are increasingly about using legitimate requests in illegitimate ways. That shifts the problem from perimeter defence to endpoint authorisation, route ownership, and business-flow protection. The decisive question is whether each API call is authorised in context, not whether it passed through a gateway.

Hidden endpoint sprawl is the specific concept teams should name and measure. API sprawl is not just more interfaces. It is a widening population of routes with inconsistent discovery, inconsistent ownership, and inconsistent control enforcement. Once that sprawl exists, remediation becomes a coordination problem across product, platform, IAM, and AppSec teams. Practitioners should manage it as a governance surface.

ASPM becomes relevant only after endpoint context is trustworthy. Correlating scanner output is useful, but it cannot compensate for missing inventory or weak authorization design. The value comes when findings are tied to live ownership, exposure, and reachable business impact. Practitioners should prioritise context before consolidation, otherwise they merely centralise noise.

From our research library:

• More than 80% of enterprises will have used generative AI APIs or deployed GenAI applications by 2026, up from 5% in 2023, according to Gartner.
• Read next: API Key Management Guide

What this signals

Hidden endpoint sprawl is becoming a measurable governance problem. The challenge is not just that APIs multiply, but that ownership, exposure, and authorisation drift across product teams faster than central controls can keep up. Once that happens, endpoint governance has to be treated as a live control surface, not a periodic inventory exercise.

API security and IAM are converging at the server-side decision point. If the request reaches a route, the application still has to prove who owns the object, who may invoke the function, and whether the call is allowed in context. That is where identity governance now intersects with AppSec in practice.

Prioritisation has to follow reachable impact, not scanner noise. According to the 2024 State of Secrets Management Survey, secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%). The broader signal is that organisations still underinvest in the control layer that decides which findings actually matter.

For practitioners

• Implement continuous API discovery Aggregate gateway, ingress, network, and repository signals into a live endpoint register that tracks exposure, owners, and data sensitivity.
• Test object ownership and function enforcement Validate every sensitive route for BOLA and BFLA by checking server-side ownership, role enforcement, and workflow authorization rather than relying on UI controls.
• Prioritise API findings by reachable business impact Correlate scanner output with ownership and data-flow context so remediation starts with routes that can expose records, invoke privileged actions, or trigger costly workflows.
• Inventory shadow and zombie APIs as distinct risks Separate never-reviewed endpoints from deprecated endpoints that still answer requests, because each class needs different ownership and retirement handling.

Key takeaways

• API security weaknesses persist because many endpoints are never fully inventoried, owned, or reviewed before they reach production.
• Broken authorization, not only injection or dependency issues, drives the most damaging API outcomes because server-side ownership checks are often absent.
• The right response is continuous discovery plus route-level context, so remediation can focus on exposed business paths rather than raw scanner counts.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect access governance, machine identity, and operational control across modern environments.