API attacks exploit design assumptions, not just bad authentication

At a glance

What this is: This is an independent analysis of why API attacks so often exploit legitimate request paths, excessive data exposure, and weak authorization assumptions.

Why it matters: It matters to IAM and security teams because APIs increasingly carry identity, access, and data decisions at runtime, and authentication controls alone do not prevent abuse of authenticated sessions, delegated access, or over-shared responses.

By the numbers:

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

👉 Read Salt's analysis of API abuse, authorization gaps, and testing blind spots

Context

API security breaks down when teams assume that successful authentication is the same as safe access. In practice, attackers often target authenticated APIs, then look for excessive data exposure, logic flaws, and missing runtime controls that let them turn ordinary requests into unauthorised access.

For identity and access practitioners, the overlap with IAM is real: APIs are now a control plane for users, services, and third parties, so authorisation, token scope, and response filtering all shape the attack surface. The article’s starting point is typical of organisations that have basic testing, but not enough runtime visibility to see how an API behaves under adversarial use.

Key questions

Q: What breaks when API security relies on bearer tokens alone?

A: Bearer-only API security breaks when a token can be intercepted and replayed by anyone who possesses it. That means the token no longer proves the sender’s identity, only possession. In practice, this increases the value of logs, proxies, and compromised endpoints as replay sources, and it makes token binding or sender-constrained designs much more important for high-risk APIs.

Q: Why do authenticated API endpoints still need strong authorisation controls?

A: Authenticated endpoints still need authorisation because identity proof does not equal request legitimacy. A logged-in user, service account, or third-party integration may be allowed to access one record but not the entire dataset. Without field-level and object-level checks, the API can disclose more data than the business intended.

Q: How do security teams know if API authorisation is actually working?

A: They should test whether each identity can only complete the specific actions it is supposed to perform, then compare that result with runtime logs and anomaly patterns. If valid credentials can still retrieve excessive data, call restricted methods, or chain privileged actions, the policy is not holding.

Q: Should organisations treat APIs as identity and access control points?

A: Yes. APIs increasingly carry user, service, and third-party access decisions, so they function as active identity control points. That means token scope, response minimisation, delegation, and lifecycle management all matter. If those controls are weak, the API becomes a pathway for unauthorised disclosure even when authentication is intact.

Technical breakdown

Why authenticated API endpoints remain exposed

Authentication proves that a caller presented valid credentials. It does not prove that the caller should see every field, object, or workflow behind the endpoint. Attackers exploit that gap by using the API as designed, then extracting more data than the front end was meant to display. Excessive data exposure usually appears when back-end services return broad records and rely on client-side filtering, which is a weak control because attackers can bypass the client entirely. The real failure is assuming that a valid session equals a safe request.

Practical implication: enforce server-side authorisation and response filtering on every endpoint, not just login gates.

How API attacks unfold over time

API abuse is often iterative rather than noisy. Attackers probe one request pattern, inspect the response, adjust parameters, and try again until they uncover logic gaps or hidden fields. That means the attack chain can stretch over hours or days, with each step appearing benign in isolation. Point-in-time scans miss this because they cannot correlate request sequences, response changes, and account behaviour over time. Runtime context is what turns a set of normal calls into a recognisable attack pattern.

Practical implication: correlate API events over time so repeated low-signal requests can be tied to a single attack path.

Why testing tools create false confidence

Static testing and generic scanning can validate syntax and known signatures, but they do not prove that an API behaves safely when exercised end to end. Many of the dangerous failures in APIs are logic failures, not simple vulnerabilities. That is why deliberately vulnerable test environments and live traffic observation matter more than checklists alone. If the testing method cannot show how the API behaves under realistic use, it cannot tell you whether the authorisation model, data minimisation, and workflow boundaries are actually working.

Practical implication: combine pre-production testing with runtime observation and adversarial validation before release.

Threat narrative

Attacker objective: The attacker wants to turn normal API access into unauthorised data access, account insight, or a foothold for deeper exploitation.

1. Entry occurs through a legitimate authenticated API request, often from a user or service account that already has access to the interface.
2. Credential or session legitimacy is then abused to enumerate objects, request broader fields, or manipulate parameters that expose excess data.
3. Impact follows when attackers exfiltrate sensitive records or use the disclosed data to support further compromise and lateral abuse.

NHI Mgmt Group analysis

Authentication-first API governance is a control gap, not a control model. The article shows how easily organisations confuse identity verification with authorisation assurance. In API environments, a valid token or logged-in user says little about whether a request should expose a given field, object, or workflow. That makes response filtering, scope enforcement, and server-side policy the real governance layer. Practitioners should treat authenticated API traffic as untrusted until authorisation is proven at the point of data release.

API abuse is a runtime identity problem as much as it is an application security problem. APIs are now the mechanism by which human users, service accounts, and third parties exchange data and permissions. That means over-permissioned service identities, weak token scoping, and delegated access paths can turn ordinary calls into unauthorised disclosure. This is where IAM and application security converge: access policy has to follow the request path, not just the login event. Teams should design API controls as identity controls in motion.

Missing correlation creates detection-response latency. The article is right that API attacks unfold over time, but the deeper issue is that many programmes still instrument individual requests rather than sequences. That creates a blind spot for low-and-slow abuse, especially when the adversary is reusing valid access. Detection-response latency: the gap between the first suspicious request and the point at which the pattern becomes visible enough to stop. Teams should shorten that gap with contextual telemetry and cross-request correlation.

The most common API failure mode is excess trust in the intended workflow. The key concept here is that developers often trust the front end, the client, or the caller to constrain what the API reveals. Once that assumption breaks, the API becomes a disclosure amplifier. The practical conclusion is straightforward: if a field is sensitive, the back end must decide whether to return it, regardless of what the caller asked for.

Adversarial testing must become part of API lifecycle governance. The article’s strongest point is not that attackers are clever, but that many API assurance processes are too static. Security teams need to validate behaviour under realistic misuse, not just confirm that a scan completed cleanly. That shifts responsibility from periodic testing to continuous verification. Practitioners should treat API security as a lifecycle discipline, not a release checklist.

What this signals

API programmes are moving from perimeter-style thinking to request-level governance, and that means identity controls now need to reach into the response path. The practical shift is toward server-side decisions on what a caller can receive, not just whether the caller can log in.

Response-path authorisation gap: when an API trusts the client to filter sensitive information, the application has already lost the control point. That gap affects human users, service identities, and third parties alike, which is why API security and IAM must be designed together. For teams formalising that model, the Top 10 NHI Issues and OWASP Non-Human Identity Top 10 are useful companion references.

As runtime telemetry improves, the next governance question is not whether an API is reachable, but whether its access patterns can be interpreted fast enough to stop abuse. Teams that rely on isolated scans will keep missing low-and-slow attacks, especially where valid credentials are reused across many calls.

For practitioners

• Enforce server-side field-level authorisation Move filtering and entitlement checks into the back end so sensitive data is never returned just because a front end omitted it. Validate that every endpoint enforces object-level and field-level decisions independently of client behaviour.
• Correlate API requests across time Build detection rules that join repeated low-risk calls, parameter changes, and response anomalies into one attack sequence. A single request may look normal, but a sequence often reveals probing, enumeration, or data extraction.
• Test APIs with adversarial workflows Use deliberately vulnerable applications, runtime traffic review, and misuse cases to see how the API behaves when a caller chains requests or escalates from legitimate access. Static scans alone will miss logic flaws and hidden response paths.
• Treat API identities as part of IAM governance Inventory service accounts, tokens, and third-party integrations that call APIs, then scope them to the narrowest necessary data and actions. Where an API exposes identity attributes or downstream permissions, review it like any other access path.

Key takeaways

• API security fails when organisations equate authentication with safe authorisation.
• The evidence in the article shows that attackers frequently work through legitimate API paths, which makes runtime visibility and response filtering essential.
• Practitioners should treat API identities, scopes, and data-return rules as part of IAM governance, not as a separate testing problem.

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.
• Runtime correlation: Runtime correlation is the practice of joining identity state changes with security activity while an investigation is still active. It lets teams evaluate whether access use matches expected behaviour, which is more useful than reviewing entitlement records after the fact.
• Server-side authorization: The practice of deciding access on the backend where an action actually executes. It prevents direct endpoint calls from bypassing UI checks and is the only place where an application can reliably stop an unauthorised mutation or data read before it happens.
• API Credential: An API credential is a secret or token that proves a workload, application, or integration is allowed to call an interface. In practice it behaves like a machine identity, so issuance, scope, rotation, and revocation all need lifecycle governance rather than ad hoc handling.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• Session-level examples of how authenticated API calls are abused to expose excess data
• Practical guidance on exercising APIs in pre-production to surface logic flaws and missing response controls
• Speaker perspectives from Corey Ball and Katie Paxton-Fear on adversarial testing and runtime analysis
• The underlying survey and incident references that support the article's API security claims

👉 Salt's full post covers the API attack patterns, runtime detection needs, and developer survey findings.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the wider access decisions that shape modern security programmes.