API security gaps widen as inventories, testing lag behind

At a glance

What this is: This is Salt’s 2024 API security survey preview, showing that API growth, incomplete inventories, and weak testing are leaving organisations exposed.

Why it matters: It matters to IAM, application security, and NHI practitioners because APIs are the control plane for machine-to-machine access, and poor discovery or authentication governance expands both credential abuse and data exposure risk.

By the numbers:

• 37% of respondents say they’ve experienced an API security incident in the past 12 months.
• Only 58% of organizations have an established API discovery process in place.
• 67% of respondents have over 10 million requests sent to applications’ APIs each month.
• Only 7.5% of organizations have implemented dedicated API testing and threat modeling programs.

👉 Read Salt’s State of API Security Report on API growth, incidents, and governance gaps

Context

API security now sits at the intersection of software delivery, identity governance, and data protection. As APIs multiply, the underlying issue is not simply volume. It is whether organisations can still discover, authenticate, authorise, and continuously monitor every interface that exposes business logic or sensitive data.

For IAM and NHI teams, APIs are where non-human identities, tokens, and delegated access become operational reality. Weak inventory, static authentication patterns, and incomplete testing create the conditions for account misuse, zombie endpoints, and data exposure that traditional documentation cannot reliably surface.

Key questions

Q: What breaks when API discovery is incomplete?

A: When discovery is incomplete, security teams miss shadow APIs, forgotten integrations, and endpoints that no longer have an obvious owner. Those gaps prevent consistent authentication, logging, rate limiting, and offboarding, which creates an easy path for attackers to find overlooked access points. An API estate cannot be governed if it cannot be inventoried.

Q: Why do APIs create identity governance risk across machine and human access?

A: APIs often carry the real access decision for service accounts, tokens, and human sessions. If an API accepts the wrong identity context, broadens scope during errors, or leaks data in failure paths, the governance model is broken even when the application appears to work.

Q: What do security teams get wrong about API posture governance?

A: They often treat it as a late-stage scan rather than an operating model. That misses the real failure mode, which is inconsistent control design across code, deployment, and runtime. A posture programme only works when standards are documented, enforced in pipelines, and validated after release.

Q: Who is accountable when a public API leaks data through valid access?

A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.

Technical breakdown

API discovery and inventory gaps

API discovery is the process of finding, classifying, and tracking every API that exists across development, test, and production environments. In practice, many organisations rely on gateway logs, code reviews, or manual registers that fall behind delivery speed. That creates orphaned endpoints, unknown versions, and stale routes that are still reachable even when teams think they have been retired. The security problem is less about not having an API policy and more about not knowing where policy needs to apply.

Practical implication: tie API discovery to deployment pipelines and runtime traffic so untracked endpoints cannot persist outside governance.

Authentication failures and account misuse in production APIs

API authentication failures often reflect weak token handling, inconsistent identity validation, or over-trusting session context across services. When an API accepts a credential that is too broad, too long-lived, or insufficiently bound to a workload or user context, account takeover and misuse become easier. This is where API security intersects directly with NHI governance, because machine-to-machine access typically depends on secrets, tokens, and service accounts that are rarely governed as tightly as human identities.

Practical implication: scope API credentials to the minimum required audience and expire them fast enough that misuse windows are short.

API posture governance and lifecycle control

API posture governance is the discipline of enforcing security controls across the API lifecycle, from design and testing through runtime monitoring and decommissioning. It combines inventory, authentication policy, vulnerability assessment, and retirement discipline into one control loop. Without it, organisations end up treating APIs as discrete development artefacts instead of long-lived exposure surfaces. The rise of AI-generated APIs makes this worse because interface creation can accelerate faster than review, documentation, or control assignment.

Practical implication: attach security gates to API design, release, and retirement so lifecycle drift does not create unmanaged exposure.

Threat narrative

Attacker objective: The attacker wants to abuse exposed API trust relationships to reach data, accounts, or backend functions that should not be directly accessible.

1. Entry begins when exposed or weakly governed APIs present reachable authentication and data-handling endpoints that attackers can enumerate through traffic analysis or simple probing.
2. Escalation follows when invalid token handling, weak authorisation checks, or account misuse allow access beyond the intended caller identity or privilege scope.
3. Impact occurs through sensitive data exposure, account takeover, or production disruption when the compromised API becomes a path into downstream systems and records.

NHI Mgmt Group analysis

API sprawl is now an identity problem, not just a development problem. The report’s data shows that discovery, authentication, and posture management are lagging behind growth, which means governance is being asked to manage interfaces it cannot reliably see. For NHIs, that is especially important because APIs are often reached with service accounts, tokens, and workload credentials that sit outside traditional human IAM processes. Practitioners should treat API inventory as a living identity map, not a static catalogue.

Zombie APIs create a standing access problem. The most dangerous API is not always the newest one. It is often the endpoint that was supposed to be retired but still responds to valid credentials or still exposes stale business logic. That pattern mirrors unmanaged non-human identity risk, where access survives longer than the workload or owner that created it. The practical conclusion is that decommissioning discipline must be a security control, not an operational afterthought.

API posture governance is the named concept this report makes unavoidable. Salt’s survey suggests many organisations still treat security as a phase-gate activity instead of a continuous posture across design, build, deployment, and runtime. That leaves authentication issues, sensitive data exposure, and unsecured endpoints to be found too late. The governance lesson is straightforward: if APIs are changing faster than your security workflow, your control model is already stale.

AI-generated APIs will intensify the visibility gap unless identity controls are built in up front. Faster API creation changes the economics of review, documentation, and approval, which means manual oversight will not scale. The more interfaces are created by automation, the more security depends on machine identity policy, scoped tokens, and runtime enforcement. Practitioners should expect API governance to merge further with NHI governance and policy-as-code.

Application security teams need to stop measuring coverage by documentation alone. A populated API register is not proof of control if authentication issues, sensitive data exposure, and weak retirement practices still dominate production. Mature programmes will align discovery, threat modelling, and runtime monitoring to the same inventory. The signal for practitioners is that governance quality, not endpoint count, is the real maturity marker.

What this signals

API governance is converging with NHI governance. As organisations automate more interface creation and machine-to-machine access, the control question shifts from how many APIs exist to which identities can reach them and under what conditions. That makes inventory, scoped credentials, and runtime monitoring a single governance problem rather than separate appsec and IAM tasks.

Zombie endpoints are a policy failure, not just a clean-up issue. When deprecated interfaces continue to accept traffic, they preserve old trust paths that attackers can still use. Practitioners should watch for shrinking review windows, rising unknown endpoint counts, and any place where decommissioning depends on manual follow-up instead of enforced workflow.

APIs with unmanaged identity context become the fastest route to privilege misuse. As machine access expands, the teams that will cope best are the ones that can align service identity, secret handling, and API posture into one lifecycle. The API inventory should behave like an identity register, not a static architecture diagram.

For practitioners

• Implement continuous API discovery Link discovery to gateways, source control, and runtime traffic so new or changed endpoints are detected before they become blind spots. Use inventory exceptions as a trigger for review, not a bookkeeping note.
• Bind machine credentials to workload context Replace broad, reusable API secrets with scoped credentials that are tied to a specific workload, environment, or service purpose. This reduces the blast radius of token theft and makes misuse easier to detect.
• Add security gates to API lifecycle events Require design review, threat modelling, authentication checks, and retirement validation at release and decommissioning stages. The aim is to stop zombie APIs from surviving after ownership, documentation, or business need has changed.
• Prioritise runtime monitoring for production APIs Use telemetry to identify unusual authentication failures, sensitive data access, and unexpected calling patterns in production APIs. Runtime signals should feed both appsec and identity teams when delegated access looks abnormal.

Key takeaways

• API growth is now outpacing the controls that should govern discovery, authentication, and retirement.
• The report’s numbers point to a maturity gap between visible API usage and the security programmes meant to manage it.
• Practitioners need lifecycle-based API governance that treats machine identity and endpoint control as one operating model.

Key terms

• API posture governance: API posture governance is the practice of managing API security as a continuous lifecycle control rather than a one-time checklist. It combines discovery, inventory, authentication policy, testing, monitoring, and retirement so that interfaces are governed from design through decommissioning.
• 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.
• Machine-to-Machine Trust: Machine-to-machine trust is the mechanism that lets systems verify each other without human intervention. It depends on cryptographic identities such as certificates, workload identities, and signing keys, which means lifecycle management and visibility are essential to keep the trust boundary reliable.
• API Coverage: API coverage describes how much of an application’s user, entitlement, and activity data is available through programmable interfaces. In SaaS management, limited API coverage constrains automation and forces teams to use manual or hybrid controls for parts of the application estate.

What's in the full report

Salt's full State of API Security Report covers the operational detail this post intentionally leaves for the source:

• Survey breakdowns showing how API incidents vary across organisation size and maturity.
• The in the wild vulnerability research behind the report’s discovery findings.
• The full set of remediation priorities for teams building API posture programmes.
• Benchmark context that helps security leaders compare their own API governance maturity.

👉 Salt’s full report includes the survey detail and in the wild research behind these API security findings

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It is designed for practitioners who need to connect identity control with modern machine-to-machine access.