TL;DR: APIs now account for more than 80% of internet traffic, and a single exposed credential or broken auth flow can open the door to unauthorised access, data theft, and abuse, according to StackHawk. The practical lesson is that API security is identity governance, access control, and lifecycle management applied at machine speed.
At a glance
What this is: StackHawk argues that API security best practices are really identity governance controls applied to machine-to-machine access, with exposed credentials and weak auth flows creating the biggest exposure.
Why it matters: IAM and security teams need to treat API controls as lifecycle, privilege, and access governance because machine traffic now carries the same business risk as human access.
By the numbers:
- APIs now account for more than 80% of all internet traffic, making them prime targets for cyberattacks.
Context
API security is the discipline of controlling who or what can call an interface, what it can see, and what it can do. In this article, the governance problem is not just traffic volume but the identity controls behind API access, especially where credentials, tokens, scopes, and lifecycle decisions are weak.
The article treats REST, GraphQL, and gRPC APIs as identity-bearing systems that need authentication, authorization, rate limits, and lifecycle management. That matters to NHI governance because API keys, OAuth tokens, and service-to-service certificates behave like machine identities once they start carrying real business access.
Key questions
Q: What breaks when authentication and authorization are treated as the same control?
A: Teams lose visibility into whether the real problem is identity proof or permission scope. That leads to weak remediation, because fixing login assurance does not reduce access blast radius, and tightening roles does not stop bad authentication. Mature IAM programmes separate the two so they can measure, govern, and audit them independently.
A: Organisations should prioritise API-based security services when they need to move quickly, support compliance requirements, and avoid repeatedly rebuilding common controls. This is especially true for teams that lack deep security engineering capacity or need consistent delivery across multiple applications. The trade-off is better speed and repeatability versus the overhead of creating and maintaining custom implementations.
Q: What are the signs that API governance is failing at runtime?
A: Common signs include undocumented endpoints, duplicated ownership, inconsistent responses, rising retry loops, and frequent discovery of APIs that are not in the catalogue. Those signals show that the live estate and the formal control model no longer match. Once that happens, security and reliability teams are managing assumptions instead of actual behaviour.
Q: How should security teams handle API keys and tokens as part of identity governance?
A: Security teams should treat API keys and tokens as governed identities, not just technical secrets. That means assigning ownership, defining scope, logging use, and removing credentials when the business process ends. The same lifecycle logic used for service accounts applies here, because stale API credentials are a common path to misuse and data exposure.
Technical breakdown
Why API authentication and authorization fail together
Authentication proves identity, but authorization constrains what that identity may do. In API environments, those two checks are often blurred, especially when teams rely on a gateway, a token, or a logged-in session as proof that access is safe. That is where broken authentication and broken object-level authorization become separate but compounding failures. A valid token can still carry excessive scope, and a correctly authenticated caller can still reach records, functions, or fields it should never see. For machine access, that turns API access into a privilege problem as much as an application security problem.
Practical implication: treat every API call as an authorization decision, not a login event.
Why API keys behave like non-human identities
API keys, bearer tokens, and service certificates are not just technical artefacts. They are durable machine credentials tied to access scope, ownership, and revocation responsibility. Once a key is embedded in code, shared across services, or left dormant, it becomes an NHI governance issue because the identity persists beyond the original deployment context. The article’s focus on least privilege, separate credentials for environments, and regular access reviews maps directly to NHI lifecycle control. If the credential can act independently in production, it needs the same scrutiny as any other privileged identity.
Practical implication: inventory API credentials as identities, then review scope, ownership, and expiry together.
How gateways centralize policy without replacing governance
An API gateway can centralize authentication, throttling, TLS termination, and logging, but it does not remove the need for policy design. The gateway is a control point, not the governance model itself. If permissions, scopes, and rate limits are not defined well upstream, the gateway simply enforces bad decisions consistently. The article’s advice to route all traffic through a gateway reflects a common architecture pattern: put repeatable controls in one place, then keep business logic separate. That helps at scale, but only if identity and access policies are already well formed.
Practical implication: use the gateway to enforce policy, not to substitute for policy design.
Threat narrative
Attacker objective: The attacker wants unauthorized API access that can be converted into data theft, abuse, or service disruption with minimal friction.
- Entry begins when an attacker or abusive client uses an exposed credential, broken auth flow, or overly permissive token to reach an API endpoint that should have been protected.
- Credential abuse continues when the caller retains valid access across endpoints, objects, or fields that exceed the intended scope of the identity or key.
- Impact follows when the attacker harvests data, automates abuse, or drives up cost through high-volume requests that bypass missing rate limits and lifecycle controls.
Breaches seen in the wild
- 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.
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
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 is identity governance, not a separate discipline: The article’s strongest point is that APIs expose the same control questions IAM teams already manage for human users and NHIs. Authentication, authorization, scope, and review all show up in machine traffic, only faster and at higher scale. Practitioners should stop treating API protection as a developer-only concern and fold it into identity governance, PAM, and lifecycle policy.
API keys and tokens create identity debt when ownership is unclear: A credential that can call production services is a governed identity, even if no human ever logs into it directly. When keys are reused across environments, left dormant, or embedded in code, the control failure is not just leakage but lifecycle drift. The practitioner lesson is to treat issuance, scope, rotation, and revocation as one continuous control surface.
Least privilege breaks down when object and field access are not modeled: The article correctly distinguishes endpoint access from object-level and field-level authorization. That distinction matters because many API incidents are not authentication failures at all, but overbroad entitlements inside a valid session or token. Practitioners need to model access at the resource level, not stop at gateway approval.
Gateway centralization helps scale policy, but it can also hide governance gaps: Putting controls in one place makes enforcement easier, yet it can also create a false sense of coverage if upstream scope design is weak. A gateway cannot correct poor entitlement modeling, weak credential hygiene, or missing offboarding. The real control is disciplined identity policy, with the gateway acting as the enforcement point.
API identity blast radius: The article shows that the true risk is not the API alone but how quickly a single credential can be turned into broad access across endpoints, objects, and environments. That is the governance problem practitioners must measure. The practical implication is to manage API access as blast-radius control, not as a one-time authentication setup.
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.
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
- Read next: Secrets Management Buyer's Guide
What this signals
API security control has become identity control: Teams that separate API hardening from IAM governance will keep missing the real failure mode, which is over-permissive machine access. The control plane needs to cover issuance, scope, review, and revocation together, not as isolated tasks.
Machine credentials create the same governance problem as human entitlements: Once an API key can reach production, the question is no longer whether the credential is valid but whether its access still matches the business use case. That is why entitlement scope and offboarding matter as much for APIs as they do for employees.
API identity blast radius: The useful lens here is how far one credential can move across endpoints, objects, and environments before it is stopped. Security teams should measure that blast radius and reduce it wherever tokens, keys, or service certificates outlive their purpose.
For practitioners
- Treat API credentials as governed identities Inventory API keys, bearer tokens, and service certificates with named owners, approved scope, and explicit expiry or review dates.
- Separate endpoint, object, and field authorization Map which API callers can reach an endpoint, which records they can touch, and which fields they can view or modify.
- Enforce least privilege by environment Issue distinct credentials for production, staging, and test systems so a lower environment cannot inherit production access.
- Review dormant access and stale keys Run periodic access reviews for API credentials, remove unused tokens, and revoke keys when roles, vendors, or integrations change.
- Centralize policy at the gateway Use the gateway to apply authentication, rate limits, TLS termination, logging, and request routing consistently across all APIs.
Key takeaways
- API security failures often start as identity failures, especially when exposed credentials or broken auth flows create broad machine access.
- The strongest control pattern is not just authentication but lifecycle-aware authorization that limits scope, review cadence, and credential reuse.
- If API keys and tokens are not governed as identities, a single compromise can turn into data theft, abuse, or service disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article starts from exposed credentials as a primary API security failure. |
| NHI-05 — Overprivileged NHI | The article repeatedly warns about excessive scopes and broad machine access. | |
| Recommendation — Scan API credentials and embedded secrets for leakage, then revoke anything exposed in code or logs. Reduce API token scope and separate credentials by environment to limit overprivileged machine access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | API callers and service identities need authentication controls appropriate to machine access. |
| IA-5 — Authenticator Management | The article emphasizes token, key, and certificate lifecycle management. | |
| Recommendation — Apply IA-9 to authenticate service and API identities before granting access to protected endpoints. Use IA-5 to manage API credential issuance, rotation, and revocation across the lifecycle. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed credentials can be reused to move across endpoints and data boundaries. |
| Recommendation — Map exposed API credentials to TA0006 and TA0008, then hunt for cross-endpoint abuse. | ||
Key terms
- API Identity: API identity is the set of credentials and attributes that lets an application, service, or script prove who it is when calling another system. It usually includes keys, tokens, certificates, or signed assertions, and it governs authentication, authorization, rotation, and auditability across machine-to-machine interactions.
- Authorization scope: Authorization scope is the set of actions and data resources a caller is allowed to access after authentication succeeds. In SMART on FHIR environments, scope is a primary security boundary because it determines whether an app can see only the records it needs or far more.
- API gateway: An API gateway is the enforcement layer that sits in front of backend services and decides how requests are authenticated, authorized, routed, logged, and rate limited. In partner ecosystems it functions as a control point for machine access, not just a traffic router, because it can unify identity and transport checks.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org