API security governance is lagging behind developer-led expansion

At a glance

What this is: This practical guide says API security now has to be built into development workflows because APIs are proliferating faster than security teams can inventory and govern them.

Why it matters: For IAM and AppSec teams, the key issue is that API access control, authentication, and authorization drift quickly when ownership, testing, and monitoring are separated from delivery.

Context

API security is the practice of controlling who and what can call an API, what data it can reach, and how the interface behaves under abuse. The governance problem in this article is scale: APIs are being created faster than security teams can inventory them, which turns exposed interfaces into blind spots rather than managed assets.

That matters for IAM and AppSec because API access is often enforced through tokens, service credentials, OAuth flows, and authorization rules that sit outside traditional user-centric controls. When APIs are designed and shipped by developers ahead of security review, the result is not just more risk, but weaker ownership over authentication, authorization, and continuous testing across the application estate.

Key questions

Q: What breaks when API inventory and ownership lag behind development speed?

A: Security teams lose the ability to prove which endpoints exist, who owns them, and which ones are exposed to the internet or to partners. That creates blind spots for authentication, authorization, logging, and testing. The practical failure is not just missed documentation. It is ungoverned surface area that can accept traffic and return data without the controls the organisation assumes are present.

Q: Why do broken authentication and authorization in APIs create such severe privacy risk?

A: Broken authentication lets an attacker reach an API without proving identity, while broken authorization lets an authenticated user access data they are not entitled to see. Together, they turn ordinary application calls into a bulk data exposure path. When APIs return profile details, device data, or account records, attackers can enumerate users, scrape records, and repurpose personal information for fraud or resale.

Q: What are the signs that API security monitoring is failing?

A: API monitoring is failing when teams cannot see request patterns, access failures, or unusual traffic in real time. Common signs include rising error rates without explanation, repeated probing that goes undetected, missing authentication logs, and delayed incident response. If logs are incomplete or not reviewed continuously, attackers can abuse APIs for longer before anyone notices.

Q: How do IAM and platform teams share responsibility for API security?

A: IAM teams should own entitlement model, lifecycle policy, and review standards, while platform teams enforce those decisions in gateways and service controls. The goal is not split accountability, but one operating model for machine access that both teams can measure and enforce consistently.

Technical breakdown

Why API inventories fall behind development velocity

Modern API estates grow through microservices, mobile backends, integrations, and AI-assisted code generation. Each of those channels can create new endpoints without a corresponding governance event, so security teams lose the ability to maintain a complete inventory. Once discovery lags, every downstream control becomes partial because you cannot test, monitor, or authorize what you do not know exists. In practice, the governance gap is not a single missing tool. It is the mismatch between how fast engineering creates interfaces and how slowly most security programmes formalise ownership, classification, and review.

Practical implication: establish authoritative API discovery and ownership before treating authentication or testing coverage as complete.

How authorization and authentication failures become data exposure

APIs frequently expose object-level and function-level access paths that are invisible in a browser-first security model. Broken object level authorization occurs when the API does not verify whether the caller should reach a specific resource, while weak authentication or session handling allows impersonation through poorly validated tokens. Excessive data exposure then compounds the problem because API responses can return more fields than the client needs. In a distributed architecture, these failures are especially dangerous because the application may appear healthy while hidden endpoints silently leak records or privileged actions remain callable by the wrong identity.

Practical implication: test API authorization at the object, function, and response-field level, not just at login.

Why security testing has to move into CI/CD

Security testing only scales when it is part of the delivery pipeline rather than a separate review gate. Static testing can flag unsafe code patterns before deployment, dynamic testing can validate live behaviour, and API-specific testing can exercise real requests and responses across endpoints. That combination matters because many API failures are behavioural, not syntactic. They only appear when the service processes realistic traffic, bad input, or edge-case authorization paths. A pipeline-integrated model also creates faster feedback for developers, which is the only sustainable way to keep pace with API growth.

Practical implication: make API testing a pipeline control, then use findings to block release only on material exposure.

Threat narrative

Attacker objective: The attacker wants to reach hidden API functions or sensitive records without being stopped by the identity and authorization controls the organisation assumes are in place.

1. Entry occurs through an exposed API endpoint that has not been inventoried or governed as part of the normal security process.
2. Credential or request abuse follows when weak authentication, broken object level authorization, or overly permissive tokens let an attacker act as a legitimate caller.
3. Impact appears as unauthorized data access, excessive data exposure, or service abuse that remains invisible until the API is observed under attack.

Breaches seen in the wild

• 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.
• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.

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 security governance debt is now the central problem. The article describes a world where developers can create API surface area faster than security teams can inventory it, and that is a governance failure as much as a technical one. Security programmes that still rely on periodic review of a bounded application estate will miss the interfaces that now carry the business logic. The practitioner conclusion is that API ownership, discovery, and policy enforcement have to be treated as ongoing control functions, not release-stage afterthoughts.

API authorization is an identity problem before it is an application problem. Every call into an API is a machine-to-machine identity event, whether the caller is a user session, service token, or workload credential. That makes authorization, token handling, and object-level access the real boundary of control in modern delivery models. Teams that separate AppSec from IAM will continue to create gaps where identity is checked at login but not at the resource or action layer.

Broken object access is the clearest failure mode in distributed APIs. When object identifiers, field selectors, or action routes are exposed without strict authorization checks, hidden business data becomes retrievable through ordinary requests. This is why the article’s emphasis on the OWASP API Security Top 10 matters: the risk is not abstract. The practitioner conclusion is that API inventories must be paired with object-level access testing and field-level response review.

CI/CD is the right control plane for API security because the attack surface is created there. If APIs are produced inside delivery pipelines, then testing, validation, and rate-limiting checks need to sit in the same path. Waiting for a downstream security review creates a gap between code release and control enforcement. The practitioner conclusion is that security teams should measure control placement by where the API is born, not where the breach is eventually found.

Cloud-native API estates need NHI-aware governance. In microservices and integration-heavy environments, APIs are consumed by service accounts, tokens, and workload identities rather than only by human users. That means the governance question extends beyond AppSec into NHI lifecycle, secret handling, and non-human access scope. The practitioner conclusion is that API security and NHI governance now overlap at the same control point: who or what is allowed to call what, under what conditions.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: LLM Provider API Key Security and LLMjacking Guide

What this signals

API security governance debt will keep widening until discovery becomes continuous. For practitioners, the immediate risk is not only exploitable endpoints but also the false confidence created by partial inventories. Teams should assume that any API estate created faster than its controls will drift into undocumented access paths, especially where service tokens and workload credentials are already in use.

Machine-to-machine access now sits at the centre of API risk. APIs are rarely governed by human login flows alone, which means NHI lifecycle, token handling, and authorization scope have to be part of the same control discussion. LLM Provider API Key Security and LLMjacking Guide is relevant here because the same credential-governance patterns apply when API keys and service tokens become the real identity boundary.

API security testing has to become a release condition, not a periodic audit. Continuous scanning and behavioural testing are the only practical way to catch object-level authorization flaws and excessive data exposure at the pace modern engineering teams ship. That shift matters most where CI/CD now creates more interfaces than security teams can review manually.

For practitioners

• Map every externally reachable API to an accountable owner Create a living inventory that records business owner, technical owner, authentication method, and data classification for each API. Treat undocumented endpoints as governance exceptions until they are assigned and reviewed.
• Enforce object-level and function-level authorization tests Test whether callers can reach another user’s record, administrative function, or hidden field by changing identifiers or request shapes. Include negative testing in automated suites so Broken Object Level Authorization is caught before release.
• Shift API security testing into the CI/CD pipeline Run static, dynamic, and API-specific tests as part of build and pre-release checks so insecure endpoints are detected while the code is still changing. Use the results to gate deployment on material exposure only.
• Harden token and secret handling for machine callers Apply short-lived credentials, secure storage, and explicit rotation policies for service tokens, API keys, and other non-human credentials that authenticate API calls. Tie those controls to the same ownership model used for the API itself.
• Baseline rate limiting and anomaly monitoring for each API class Set differentiated throttling and request limits for public, partner, internal, and high-risk endpoints. Monitor for bursts, enumeration patterns, and unusual error rates that indicate abuse or brute-force activity.

Key takeaways

• API security fails fastest when discovery, ownership, and authorization drift away from the teams creating the endpoints.
• The article’s core warning is that machine-to-machine access turns API calls into identity events that must be governed like credentials, not just code.
• Security testing needs to sit inside the delivery pipeline if organisations want to catch object-level access flaws before they become production exposure.

Key terms

• API Security: API security is the set of controls that inspect and constrain requests at the boundary of an exposed interface. It validates schemas, scopes, and traffic behavior after a credential is already present, which means it complements identity governance but does not replace it.
• 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.
• Excessive Data Exposure: Excessive data exposure occurs when an API returns more information than the caller actually needs. The issue is usually a design and authorization problem rather than a coding typo, and it increases breach impact because a stolen credential can reveal far more data than intended.
• Machine-to-Machine Identity: Machine-to-machine identity is the identity used by services, workloads, tokens, and API callers that are not human users. In API security, it determines who or what can authenticate, what scope it receives, and how access is governed across systems.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a shared foundation for governing non-human access alongside API and application controls.