API security gaps expose authentication and access control failures

At a glance

What this is: StackHawk argues that web API security fails most often at authentication, authorization, input validation, and rate limiting, leaving APIs exposed to unauthorized access, data leakage, and disruption.

Why it matters: For IAM, PAM, and application security teams, the article reinforces that API trust must be enforced at the request level with least privilege and continuous testing, not assumed from network location.

Context

APIs are now core access paths for application data and functionality, which means security gaps at the API layer quickly become governance gaps. When authentication or authorization is weak, the issue is no longer just application hardening. It becomes an access-control problem that can expose sensitive data, elevate privilege, or let abusive traffic consume shared services.

That matters to identity and access practitioners because APIs increasingly depend on machine-to-machine trust, token handling, and fine-grained permissioning. The article's central message is that perimeter controls are not enough for API risk. Security has to move closer to issuance, validation, and request-level authorization, where non-human access is actually exercised.

Key questions

Q: What breaks when API authentication is correct but authorisation is weak?

A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement. That failure usually appears as BOLA, broken function-level access, or mass assignment. Security teams should test whether an authenticated caller can move from one object, record, or action to another without additional approval.

Q: Why do broken object and function level authorization failures create such severe risk in API-driven financial systems?

A: They let an authenticated user act far beyond intended permissions, which turns a single weak session into broad data exposure, account tampering, and service disruption. In financial environments, that can expose regulated records, enable account takeover, and support fraud. The risk rises sharply when object identifiers are guessable, authorization checks are inconsistent, or rate limits are missing.

Q: What are the signs that an API authorization control is failing in practice?

A: Common warning signs include endpoints returning valid data without a token, access to records that should be scoped to another user, and responses that expose credentials or keys in configuration data. Another indicator is when iterating a parameter reveals large volumes of records in predictable increments. Those patterns suggest broken object or function level authorization, not just a minor configuration issue.

Q: How should security teams secure APIs that rely on machine-to-machine credentials?

A: Security teams should replace reusable shared secrets with short-lived, scoped credentials and bind them to a verified client identity. mTLS and private_key_jwt are stronger because they reduce replay risk and tie access to the connecting workload or partner. The goal is to make stolen credentials much less useful.

Technical breakdown

Broken authentication in API sessions and tokens

API authentication establishes whether a caller is who or what it claims to be, usually through tokens, session state, or federated credentials. When that layer is weak, attackers can bypass login, replay stolen tokens, or impersonate users and services. In API environments, the problem is often not just password weakness but insecure token handling, poor session management, or missing checks on credential integrity. Because APIs are designed for automation, failures here can be exploited at machine speed across many endpoints at once. That makes authentication a lifecycle control, not a one-time gate.

Practical implication: treat API authentication as a credential lifecycle problem and test token handling, expiry, and replay resistance continuously.

Authorization gaps at object and function level

Authorization decides what an authenticated caller can do, and API failures often appear as broken object level authorization or broken function level authorization. BOLA occurs when a request can reach data or objects that should be inaccessible to that caller. BFLA occurs when an endpoint allows actions the caller should not be able to perform. These are especially dangerous because the application may appear to authenticate correctly while still exposing excessive access. In identity terms, the caller has an identity, but the entitlement model is too coarse or inconsistently enforced across endpoints.

Practical implication: verify authorization on every API route and object, not just at login, and align permissions to the smallest workable scope.

Why input validation and rate limiting are security controls, not hygiene

Input validation blocks malicious or malformed requests before they reach application logic, while rate limiting constrains abuse, denial of service, and automated probing. In API security, these are not peripheral safeguards. They are control points that prevent injection, resource exhaustion, and repeated exploitation attempts from turning a single weak endpoint into a broad incident. If validation is inconsistent or throttling is absent, attackers can chain noisy requests into discovery, abuse, or service disruption. That is why the article frames testing and monitoring as continuous rather than occasional. The control must operate at runtime, not just in development.

Practical implication: enforce schema validation and request throttling at the gateway and service layer, then verify both under load and attack conditions.

Threat narrative

Attacker objective: The objective is to reach data or functionality that the API exposes while avoiding the intended access controls and, where useful, causing service disruption.

1. Entry occurs through an exposed API endpoint that accepts untrusted requests without sufficient authentication or validation.
2. Credential or authorization weaknesses then let an attacker impersonate a caller, access objects outside intended scope, or invoke functions that should be restricted.
3. The attacker can then extract data, trigger abuse of application functionality, or overwhelm the service until legitimate users are affected.

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.
• 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.

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 now an identity problem as much as an application problem. The article's core risk is not simply insecure code. It is that APIs act as enforcement points for machine and human access, so weak authentication and authorization become governance failures. For IAM and PAM teams, the real question is whether access is being evaluated at request time with enough granularity to stop privilege drift.

Broken object and function authorization should be treated as entitlement design failures. When APIs expose objects or methods beyond the caller's intended scope, the control model is too broad, not merely incomplete. That pattern maps cleanly to least privilege discipline and to the operational reality that many APIs still trust coarse roles more than context. Practitioners should assume entitlement boundaries will be tested, not respected.

API abuse exposes a gap between developer testing and live runtime control. Input validation, throttling, and error handling often look adequate in code review but fail under scripted abuse, malformed traffic, or high-volume probing. That means assurance has to move beyond release-time checks and into continuous DAST, telemetry, and request monitoring. The control plane must see what the endpoint actually does under pressure.

Named concept: request-time access governance. This article shows why API security cannot rely on static trust around authenticated users or services. Access has to be governed at the moment of each request, because token possession alone does not prove the caller should see a given object or invoke a given function. Teams should redesign their controls around that assumption.

Machine credentials make API security inseparable from NHI governance. Where services, workloads, and automations call APIs, the identity being evaluated is often non-human. That makes token scope, rotation, inventory, and revocation part of the security model, not an adjacent hygiene task. The practical conclusion is that API protection and NHI governance now sit on the same control path.

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.
• Read next: API Key Management Guide

What this signals

Request-time access governance: API security is increasingly decided at the moment of each request, not at the perimeter. That shifts the control objective from keeping attackers out of the network to proving every call is entitled to the specific object and action it is trying to reach. For practitioners, that means authorization telemetry and token scope review belong in the same programme.

Machine credentials make the API problem inseparable from NHI governance, because many API calls are now made by services, workloads, and automation rather than humans. Once those identities are in play, token inventory, ownership, rotation, and offboarding become part of access control itself. The programme implication is clear: if you cannot inventory the callers, you cannot confidently govern the API surface.

For practitioners

• Tighten token and session controls Review API token issuance, expiry, revocation, and replay handling so machine and user credentials cannot be reused outside intended sessions.
• Enforce object-level authorization Check every sensitive endpoint for per-object access checks so a valid login cannot be used to read or modify records outside the caller's scope.
• Add runtime validation and throttling Push schema validation, sanitization, and rate limits into gateway and service controls, then test them under malformed and high-volume request patterns.
• Map API callers to NHI inventory Catalogue service accounts, API keys, and workload tokens that call your APIs, and assign owners for rotation, revocation, and offboarding.
• Prove authorization under attack conditions Use active testing to confirm that broken function level authorization and broken object level authorization do not appear when endpoints are probed directly.

Key takeaways

• API breaches often begin with authentication that is technically present but operationally weak, allowing a caller to look legitimate while still overreaching.
• The real exposure is usually authorization, where object-level and function-level gaps let valid identities access data or actions outside their intended scope.
• Runtime testing, validation, and throttling are the controls that turn API security from a design assumption into an enforceable operating model.

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.
• 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.
• API Token Lifecycle: API token lifecycle is the full journey of a token from creation to retirement. It covers issuance, storage, use, rotation, renewal, revocation, expiration, and audit logging. In identity security, lifecycle control limits exposure, reduces replay risk, and ensures tokens remain tied to approved services, scopes, and time bounds.
• Request-time Authorisation: Request-time authorisation is the practice of checking policy at the moment an action is attempted rather than only at login or provisioning. For AI agents, this matters because identity context and tool choice can change during a session, so earlier decisions may no longer be valid.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It helps security and identity practitioners connect machine access controls to the broader programme they are responsible for.