API security governance is lagging behind developer-led expansion

At a glance

What this is: This is a practical guide to API security that frames APIs as an expanding attack surface and outlines the core controls needed to protect them.

Why it matters: It matters because API security now sits at the intersection of AppSec, IAM, and workload trust, where authentication, authorization, and token handling directly affect how access is governed.

👉 Read StackHawk's practical guide to API security for developers and security teams

Context

API security is the discipline of protecting programmatic interfaces that move data and actions between services, apps, and integrations. The governance problem is that APIs are often created faster than they are inventoried, so organisations lose visibility before they lose control. In identity terms, that means authentication and authorization decisions are being made across a surface that is neither fully known nor consistently reviewed.

That creates a direct bridge to IAM, workload identity, and NHI governance because API access is frequently enforced through tokens, service accounts, and other non-human credentials. When developers ship APIs continuously, security teams need controls that scale with delivery rather than arrive after deployment. The article treats that as the central operational tension, and that starting position is common in modern application estates.

Key questions

Q: How should security teams reduce API attack surface without slowing delivery?

A: Start by making API discovery part of the release process, then test authorization at the object and function level before every deployment. Pair that with gateway enforcement, token lifecycle management, and runtime monitoring so new endpoints do not become unmanaged trust paths. Delivery stays fast when the control set is automated and owned across engineering and security.

Q: Why do APIs create governance problems for IAM teams?

A: APIs turn identity decisions into machine-to-machine enforcement problems. Tokens, scopes, service accounts, and roles all shape what a caller can do, but those controls are easy to overextend when teams optimise for delivery speed. IAM teams need to treat APIs as a place where identity scope must be tested continuously, not assumed from design.

Q: What breaks when Broken Object Level Authorization is missed?

A: A valid user can often retrieve or modify another user’s data by changing an identifier in the request. The application may still appear authenticated, which makes the failure easy to overlook until data leakage or abuse appears. This is one of the most common ways API security collapses in production.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Technical breakdown

Why broken object-level authorization is the first API failure mode

Broken object-level authorization occurs when an API checks that a requester is authenticated but not whether they are allowed to access a specific object. Attackers exploit predictable identifiers, changing account or record IDs to reach data belonging to other users. This is especially dangerous in microservice environments where each service may trust upstream context without re-validating the final access decision. The failure is not just one endpoint, but a pattern of assuming that identity alone proves entitlement.

Practical implication: enforce object-level authorization checks on every sensitive API call, not just at the gateway.

How authentication, tokens, and session handling fail in API environments

APIs often rely on OAuth 2.0, OpenID Connect, JWTs, or similar tokens to represent identity and scope. The risk appears when tokens are overlong, poorly validated, stored insecurely, or accepted across contexts they were never meant to cover. In practice, broken authentication is often a lifecycle problem as much as a cryptographic one, because stale, mis-scoped, or replayable tokens turn temporary trust into persistent access. That is where API security overlaps with identity governance and secrets management.

Practical implication: bind token lifetimes, scope, and validation rules to the exact workload and API context.

Why rate limiting and schema enforcement are part of abuse resistance

APIs do not fail only through theft of access. They also fail through abuse of allowed access, including brute force, scraping, query amplification, and injection. Rate limiting constrains request volume, while schema validation and output sanitization constrain what a request can ask for and what a response can reveal. In GraphQL and microservices environments, the challenge is sharper because flexible queries and chained services can multiply impact from a single request path. Security controls therefore need to manage both identity-backed access and machine-speed misuse.

Practical implication: pair rate limiting with schema validation and anomaly monitoring so approved clients cannot weaponize normal access.

NHI Mgmt Group analysis

API security is now an identity governance problem as much as an application security problem. The article is correct to emphasise authentication and authorization, but the deeper issue is that API access is increasingly mediated by tokens, service accounts, and service-to-service trust. That means entitlement review, token scope, and credential lifecycle controls matter as much as code-level testing. Practitioners should treat API governance as part of IAM and NHI oversight, not as a separate control island.

Developer velocity has outgrown manual visibility models. When AI-assisted coding and microservice delivery generate APIs daily, security teams cannot rely on periodic discovery or late-stage review. This creates an inventory gap before it becomes a vulnerability gap. API surface sprawl: the growing mismatch between the number of live APIs and the organisation's ability to map, classify, and secure them. Practitioners need continuous discovery tied to ownership and risk classification.

Broken authorization is more often a trust-design failure than a point-in-time bug. The article's risks list shows that object-level access, session handling, and data exposure failures all stem from assuming the request boundary is trustworthy once authentication succeeds. That assumption breaks in distributed systems where downstream services inherit context without re-checking it. Practitioners should push policy closer to the resource and revalidate access at each sensitive hop.

OWASP API Security Top 10 remains the most useful operational baseline because it maps directly to attack paths. The article's discussion of BOLA, broken authentication, excessive data exposure, rate limiting, and injection aligns with a control-oriented view of API risk rather than a purely architectural one. That matters because teams need a shared vocabulary for prioritisation across development, AppSec, and IAM. Practitioners should use the OWASP lens to decide which APIs need stronger controls first, especially where non-human credentials are in play.

What this signals

API surface sprawl will become a board-level governance issue wherever AI-assisted development increases the number of service endpoints faster than security teams can classify them. The practical response is continuous discovery linked to ownership, data sensitivity, and workload identity. That is the only way to keep API risk from becoming an unmanaged shadow layer inside the application estate.

The strongest programmes will treat API control as an extension of IAM, not a separate AppSec checklist. That means tighter token scope, shorter credential lifetimes, and policy enforcement at the resource level, supported by controls such as the NIST SP 800-53 Rev 5 Security and Privacy Controls and the MITRE ATT&CK Enterprise Matrix. Practitioners should expect more overlap between application security and identity governance operating models.

The governance signal is clear: if an organisation cannot map which APIs exist, who owns them, and which non-human credentials can reach them, it does not have an API security programme so much as a partial control set. For identity-led teams, that should trigger tighter alignment with secrets management, service account review, and least-privilege policy design.

For practitioners

• Inventory APIs continuously across delivery pipelines Track APIs as they are created, changed, and retired, with ownership, data classification, and authentication method recorded for each endpoint. Use discovery that runs close to CI/CD and production so the inventory reflects the live surface, not last quarter's architecture diagram.
• Enforce object-level authorization at every sensitive endpoint Require explicit access checks on object identifiers, not just user login state, and test for BOLA patterns in every service that exposes records, files, or account resources. Treat broken authorization as a policy defect, not only a code defect.
• Bind token scope and lifetime to workload context Set short token lifetimes, narrow scopes, and strict validation rules for service-to-service access, especially where APIs are reached by automation or non-human credentials. Revoke and reissue tokens when workload roles change or when an integration is no longer trusted.
• Throttle abuse without blocking legitimate automation Apply rate limits by client type, endpoint sensitivity, and anomaly profile, then test whether legitimate integrations still function under burst conditions. Combine throttling with schema validation so permitted clients cannot turn volume into data extraction or denial of service.
• Shift security testing left and keep it running in production Use SAST, DAST, and API-specific testing in CI/CD, then add runtime monitoring for unusual authentication patterns, response sizes, and query complexity. The goal is to catch regressions early and detect abuse when a secure build starts behaving insecurely.

Key takeaways

• API security is no longer only an AppSec concern because API access is governed through identities, tokens, and service-to-service trust.
• The dominant failure modes are broken authorization, weak token handling, data overexposure, and abuse of allowed access through volume or query complexity.
• Teams that continuously discover APIs, enforce policy close to the resource, and test in the delivery pipeline will govern risk more effectively than teams relying on periodic review.

Key terms

• 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.
• API Surface Sprawl: The growth of live, exposed, and often under-inventoried APIs across applications, services, and integrations. It becomes a governance problem when security and ownership records cannot keep up with the rate at which new endpoints are created or changed.
• Token scope: Token scope is the set of actions and systems a credential can reach. In non-human identity governance, narrow scope limits blast radius, while broad scope lets a stolen token publish packages, access cloud services, or mutate repositories far beyond its intended purpose.
• Rate Limiting: A control that restricts how many requests a caller can make within a defined period. It protects availability and reduces abuse, but it only works when paired with correct authentication, authorisation and endpoint design.

What's in the full article

StackHawk's full guide covers the operational detail this post intentionally leaves for the source:

• Endpoint-by-endpoint guidance on implementing authentication and authorization patterns in real application stacks
• Implementation examples for rate limiting, input validation, and output sanitization across REST, GraphQL, and microservices APIs
• Testing workflow details for SAST, DAST, and API-specific scanning inside CI/CD pipelines
• Practical security control comparisons for teams deciding how to enforce API policy at scale

👉 StackHawk's full guide covers API risks, control patterns, and testing approaches in more implementation detail.

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 is designed for practitioners who need to connect identity controls to real operational risk across modern delivery environments.