API attacks exploit design assumptions, not just bad authentication

At a glance

What this is: Salt argues that API attacks frequently exploit design assumptions, especially when legitimate requests return more data than the caller needs.

Why it matters: This matters because IAM and API security teams cannot treat successful authentication as proof of trust when authorization, data minimisation, and runtime abuse remain unconstrained.

By the numbers:

• 94% of API attacks occur against authenticated endpoints and users.
• Only 4.3% of developers were conducting security testing on APIs.

Context

API security fails most visibly when teams trust authentication as a proxy for authorization. In practice, an endpoint can be working exactly as designed while still exposing excess data, weak logic flow, or reusable outputs that support later abuse.

This article sits at the intersection of API security and identity governance because authenticated access is not the same as governed access. For IAM and NHI practitioners, the key issue is whether an API call is both allowed and constrained to the minimum data and action set required.

The article’s starting position is typical of many organisations: strong emphasis on access entry, weaker emphasis on what an authenticated session can actually do once inside.

Key questions

Q: What breaks when an API assumes authentication is enough for trust?

A: The trust model breaks at the authorization layer. A valid login or token does not guarantee the caller should see every object, field, or workflow the API can return. When teams treat authentication as the whole security decision, attackers can exploit normal requests to access excessive data or invoke business logic they should never reach.

Q: Why do authenticated API users still create security risk?

A: Because valid credentials can still be abused. Attackers often steal keys, tokens, or user credentials and then use the API exactly as designed, which makes the activity look legitimate at the protocol level. The risk sits in what the caller can access and how much data they can retrieve, not just in whether they passed authentication.

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

A: Common warning signs include spikes in 403 responses, bursts of schema violations, sequential ID access, repeated webhook IDs, and tokens reused across services. Those patterns usually mean authorization is weak, contract enforcement is drifting, or replay protection is incomplete. Teams should correlate runtime signals with negative tests and owner metadata to find the broken control quickly.

Q: Should teams prioritise API authorization testing over authentication testing?

A: They should treat them as different controls and prioritise authorization testing whenever the business risk is data exposure or workflow abuse. Authentication proves who or what is calling. Authorization proves what that caller can do and see, which is where many API incidents actually happen. Both matter, but they fail differently.

Technical breakdown

Why authenticated API traffic still creates attack exposure

Authentication proves a caller presented valid credentials. It does not prove the caller should receive every field, object, or business action that the API can technically return. When back-end APIs are built to trust front-end filtering, or when object and field checks are incomplete, the caller can legitimately request data and still receive more than intended. That is why excessive data exposure and authorization flaws are so damaging. The abuse path is often hidden inside normal request flows, which makes the issue look like ordinary use rather than malicious activity.

Practical implication: verify authorization and response filtering at the API layer, not only at the application edge.

How adversaries turn valid requests into data exfiltration

A common API abuse pattern is to stay within the designed request path while extracting unnecessary or sensitive fields from the response. This can include usernames, MFA status, account metadata, or PII that was never meant to be visible to the caller. The attacker does not need to break authentication if the API exposes logic gaps after authentication succeeds. This is why API3 excessive data exposure remains a practical issue, especially where business convenience and broad responses were prioritised over data minimisation and object-level control.

Practical implication: minimise response payloads and test whether each field is justified for the caller’s role and use case.

Why API attacks require context over time

API attacks often unfold slowly, with repeated probes, changed inputs, and incremental discovery across hours or days. Static testing can miss these patterns because it sees isolated requests, not the attacker’s sequence. Event correlation matters because the real weakness may be the combined effect of several “normal” calls that only become suspicious when viewed together. This is one reason runtime observation is more valuable than a one-off scan, especially for APIs that serve third parties, mobile apps, or distributed services.

Practical implication: correlate API events over time so repeated low-and-slow abuse is visible before exfiltration completes.

Threat narrative

Attacker objective: The attacker’s objective is to extract sensitive data and use legitimate API behaviour to increase reach without triggering obvious access failures.

1. Entry begins with an authenticated caller using the API exactly as designed, which gives the attacker a legitimate-looking foothold.
2. Credential or session legitimacy is then used to request responses that expose more data than the original business purpose required, including sensitive account metadata or PII.
3. The attacker repeats and adapts requests over time, using the exposed data to expand access or prepare follow-on abuse.
4. Impact occurs when excess data is exfiltrated or when the leaked context enables broader compromise of accounts, workflows, or dependent systems.

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

Authentication is not an authorization model: once a caller is inside an API, the security question becomes what data and actions that identity can actually justify. The article’s core warning is that many organisations still over-trust successful login or token validation as if it covered the whole risk decision. For IAM and API governance, that is a control boundary error, not a minor tuning issue. Practitioners should treat authorization and data minimisation as first-class controls, not post-authentication refinements.

API abuse is often a logic problem, not a vulnerability scanner problem: attackers frequently use APIs exactly as designed and still reach unintended data. That means a clean static scan can coexist with a dangerous runtime weakness if response construction, object selection, or field exposure is wrong. The article reinforces a governance gap that is common across identity-linked APIs: policy has to bind to the request context and returned data, not just the login event. Practitioners should test business logic, not just endpoint reachability.

Excessive data exposure is a governance failure of least-data design: the right question is not only whether an endpoint is accessible, but whether the response is narrowly scoped to the caller’s purpose. This is where API security intersects with identity governance, because entitlement and data visibility must be evaluated together. When authenticated users routinely receive more than they need, the organisation has expanded its attack surface through its own design choices. Practitioners should measure whether each field is necessary before release.

Low-and-slow API attacks demand runtime visibility, not one-shot verification: the article is right that these attacks may unfold over hours or weeks, which defeats control models that only inspect isolated calls. That makes detection engineering and event correlation part of API governance, especially where third-party integrations or distributed services are involved. The broader signal is clear: teams that separate development testing from runtime assurance will keep missing attack chains. Practitioners should align API testing with operational telemetry and repeated abuse patterns.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

Least-data design: API programmes should stop treating full-record responses as harmless convenience. The practical shift is to design responses around the minimum fields needed for the caller’s task, then verify that production telemetry matches that intent.

Attackers do not need a broken login screen if the API itself returns excess context after authentication. That is why API governance must move from “can this caller enter?” to “what can this caller learn or do once inside?”

For practitioners

• Harden authorization at the response layer Enforce object-level and field-level checks on every API response so authenticated callers only receive data that matches their role and business purpose.
• Minimise payloads by default Review each endpoint to remove unnecessary fields, suppress sensitive metadata such as MFA status unless required, and redesign responses around least-data principles.
• Correlate API events over time Build detection logic for repeated probes, shifting request patterns, and low-and-slow abuse that only becomes visible across multiple calls.
• Exercise APIs in pre-production Test business logic and runtime behaviour with real request flows, because static analysis alone will miss missing decision points and misleading green results.
• Separate front-end trust from back-end control Do not rely on client-side filtering or application-layer assumptions to protect sensitive data when the API itself can return the full record.

Key takeaways

• API attacks frequently succeed because the endpoint works exactly as designed, which leaves authorization and data minimisation as the real control points.
• Salt’s analysis highlights that 94% of API attacks occur against authenticated endpoints and users, so identity proof alone is not a sufficient safeguard.
• The most effective countermeasure is to combine runtime visibility with response-level authorization and least-data design.

Key terms

• 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.
• 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.
• Runtime API Abuse: The misuse of a working API through valid requests, repeated probing, or subtle parameter changes that reveal logic gaps. It is hard to catch with static checks alone because the weakness appears in how the API behaves during real execution, not just in code structure.
• Least-data Design: An API design principle that returns only the minimum fields and objects required for a legitimate task. It reduces the value of any single request to an attacker and forces security teams to justify data exposure instead of assuming broad responses are acceptable.

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 helps practitioners connect identity controls to the broader access decisions their programmes depend on.