API vulnerabilities expose object access, auth, and data controls

At a glance

What this is: StackHawk outlines six common API vulnerability classes and argues that the core risk is weak control over access, authentication, object references, and request volume.

Why it matters: IAM, AppSec, and NHI teams should treat API security as an identity and authorisation problem because broken object access and broken authentication can expose both human and machine-controlled data paths.

Context

API vulnerability management is not just about scanning code for bugs. It is about proving that every request is bound to the right identity, the right object, and the right scope, because APIs often become the control plane for business data and workflows.

That makes the topic relevant to IAM and NHI governance as well as AppSec. Service accounts, API keys, tokens, and delegated access paths can all fail in the same way human logins do when authentication is weak or authorization is checked too late.

StackHawk’s article is best read as a catalogue of control failures, not as a product story. The typical pattern is familiar: a technically working API still leaks data or permits actions because identity and object-level guardrails were not enforced consistently.

Key questions

Q: What breaks when API authorization only checks the logged-in user, not the object being accessed?

A: Broken object-level authorization creates a gap where an authenticated caller can still reach records, properties, or functions it should never see. That failure is especially dangerous in APIs because attackers can automate identifier changes, enumerate resources, and extract data without obvious login anomalies. The right control is object-level enforcement on every request.

Q: Why do broken API authentication controls create such a large breach risk?

A: Broken API authentication is dangerous because a valid caller can be accepted before any deeper control has a chance to stop abuse. Once a token or key is trusted, an attacker can access the same functions and data that the legitimate integration can reach, which makes overprivilege and stolen credentials especially costly.

Q: What are the signs that an API is being probed for abuse?

A: Common signs include repeated tweaks to user IDs or object IDs, a growing number of errors from the same entity, and requests that test privilege escalation or access boundaries. The key signal is not one failed request, but a sequence of small, unusual behaviors that together suggest reconnaissance rather than normal use.

Q: When should organisations prioritise rate limiting over request validation for API protection?

A: Prioritise rate limiting when the immediate problem is request volume, abuse, or repeated calls that can exhaust capacity or distort service behaviour. Use request validation when the main risk is malformed input, schema violations, or unexpected payloads reaching the application. In mature environments, both controls are complementary: one protects availability, the other protects request integrity.

Technical breakdown

Broken object authorization and direct object references

Broken object level authorization occurs when an API lets a caller change an object identifier and reach data it should not see. In practice, this is the same control failure that underlies IDOR, where predictable IDs or missing server-side checks let a requester move from one record to another. The danger is not the identifier itself, but the absence of a trusted authorization decision at the object boundary. When APIs expose customer records, account metadata, or internal workflow objects, object access must be verified on the server for each request, not assumed from the client path or token alone.

Practical implication: enforce server-side object checks for every sensitive API call, not just at login or session creation.

Broken authentication, tokens, and session trust

API authentication fails when the system accepts weak, stolen, stale, or poorly validated credentials as proof of identity. That can happen through guessable passwords, missing JWT expiration checks, inadequate session management, or poor token handling. For machine-to-machine traffic, the same pattern affects API keys and service credentials, which often live longer and travel farther than human sessions. The governance lesson is that authentication is not a one-time gate. It is a lifecycle control over credential strength, expiry, validation, and revocation across both human and non-human access paths.

Practical implication: treat API credentials as lifecycle-managed authenticators and validate expiry, revocation, and scope on every use.

Rate limiting, injection, and unsafe API consumption

APIs become fragile when request volume is unchecked or when input from untrusted sources is processed without validation. Lack of rate limiting enables brute force, scraping, and denial-of-service pressure, while injection flaws let attackers smuggle malicious input into queries or backend actions. These are different attack modes, but they converge on the same result: the API behaves as a trusted interpreter of hostile input. In modern environments, this also includes unsafe consumption of downstream APIs, where one insecure interface becomes the feeder path for another. Security teams need to think in terms of trust boundaries and request shaping, not just code hygiene.

Practical implication: combine throttling, input validation, and traffic monitoring so hostile request patterns are blocked before they reach business logic.

Threat narrative

Attacker objective: The attacker wants unauthorized access to data or actions through API paths that were exposed without adequate authentication, authorization, or traffic control.

1. Entry begins when an attacker finds an API endpoint with weak authentication, predictable object references, or missing request throttling.
2. Credential or object access is then abused to enumerate records, bypass authorization checks, or invoke sensitive functions that should have been denied.
3. Impact follows as confidential data is exposed, internal workflows are manipulated, or service availability is degraded through abusive request volume.

Breaches seen in the wild

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

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 control problem, not just an application bug problem. The article’s six vulnerability classes all reduce to the same governance issue: who or what is allowed to access which object, function, or data set through an API. That matters because APIs increasingly carry both human and non-human access, so IAM and NHI teams must treat authorization as a runtime enforcement problem rather than a login event. Practitioners should align API control design with identity governance, not leave it isolated inside AppSec.

Broken object access is the clearest sign of API governance debt. When object IDs, business flows, or backend functions can be manipulated from the client side, the system is depending on fragile assumptions about caller honesty. That creates a trust gap between authentication and authorization, and it is exactly where many data exposure incidents begin. The practical conclusion is that object-level enforcement should be a first-class control in API governance, not a follow-on test case.

Machine credentials amplify API risk because they are often overused and under-governed. API keys, tokens, and service identities tend to persist across systems, pipelines, and integrations, which makes weak validation or poor scoping especially dangerous. This is where NHI governance intersects directly with AppSec: the credential may authenticate successfully even when its business context is stale or excessive. Practitioners should treat machine-to-machine API access as an identity lifecycle problem with inventory, scope, and revocation requirements.

Rate limiting and monitoring are governance controls, not just performance controls. The article frames throttling as protection against denial of service, but it also functions as an abuse-detection boundary for credential stuffing, scraping, and brute force patterns. That means API telemetry belongs in both security monitoring and identity governance, especially where service accounts or delegated access are involved. Teams that cannot observe request volume by identity cannot reliably distinguish normal automation from hostile automation.

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

API control failure is becoming a governance issue for identity teams as much as for AppSec. Once APIs carry delegated access, service credentials, and business-critical object paths, the boundary between application security and identity governance disappears. Teams should align API reviews with entitlement review, because the question is no longer whether an endpoint works, but whether its access model is defensible.

Object-level authorization should be treated as a default control expectation for sensitive APIs. The biggest practical gap is not missing encryption or missing documentation, but missing server-side proof that the caller can touch the specific object involved. If that proof is absent, the API is effectively exposing business records by design rather than by exception.

For practitioners

• Enforce object-level authorization on every API request Verify the caller’s entitlement against the specific object or record being requested, not just the endpoint or session. Use server-side checks for reads, updates, and deletes so predictable IDs cannot be used to cross tenant or account boundaries.
• Harden API authentication lifecycles Set explicit expiry, rotation, and revocation rules for API keys, tokens, and service credentials, then validate them at each call. Treat long-lived authenticators as a policy exception rather than the default operating model.
• Throttle abusive request patterns Apply rate limits and anomaly thresholds to sensitive endpoints, especially login, lookup, export, and search functions. Monitor for enumeration, burst traffic, and repeated object access attempts that suggest automation abuse.
• Inventory exposed and deprecated API versions Map all active API versions, including legacy and shadow endpoints, so security testing and policy enforcement cover the full attack surface. Remove or segment versions that no longer need production access.
• Test APIs for injection and excessive data exposure Run SAST and DAST checks against parameter handling, response shaping, and backend query paths. Confirm that APIs return only the fields and records the caller is authorised to receive.

Key takeaways

• API vulnerabilities are often access-control failures in disguise, which is why they sit at the intersection of AppSec, IAM, and NHI governance.
• Broken object authorization, broken authentication, and IDOR are especially dangerous because they let attackers use valid-looking requests to reach unauthorized data or functions.
• The most effective response is not a single scanner rule but a control model that combines object-level checks, authenticated request validation, throttling, and API inventory discipline.

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 Authentication: Broken authentication is a failure in how a system proves that a caller is who or what it claims to be. For APIs, that often means weak token handling, replayable credentials, or poor validation of delegated access, which allows unauthorised callers to act as trusted integrations.
• 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.
• Insecure Direct Object Reference: Insecure direct object reference is an access control flaw where an application exposes an identifier that allows callers to reach records or objects they should not be able to access. In practice, it means the system trusts the request too much and fails to verify object-level permission on each access.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.