API attacks are exploiting governance gaps and stolen credentials

At a glance

What this is: Salt argues that API attacks succeed by abusing visibility gaps, weak governance and stolen credentials rather than by relying only on classic malware or perimeter intrusion.

Why it matters: For IAM, PAM and application security teams, the issue is that API access often depends on secrets, tokens and business logic that sit outside normal identity controls and are difficult to govern continuously.

By the numbers:

• 95% of CISOs worldwide say their organisation has made API security a planned priority over the next two years.

Context

API attacks are a governance problem as much as a technical one. Modern applications expose business functions and data through application programming interfaces, but many organisations still lack complete inventory, consistent ownership and lifecycle controls for those interfaces. That leaves shadow and zombie APIs outside normal review, which turns routine access paths into hidden attack surfaces.

The identity angle is direct. APIs are frequently secured by keys, tokens and delegated credentials, so poor discovery and poor credential governance can combine into one failure mode: unauthorised actors operating through apparently legitimate access. In that sense, API security is not only an application control issue but also an IAM, PAM and NHI governance issue when machine credentials and service access are involved.

Key questions

Q: What breaks when APIs are not centrally discovered and governed?

A: Undiscovered APIs create blind spots that bypass ownership, review and policy enforcement. Shadow and zombie endpoints can remain reachable long after teams assume they are retired or protected, which means attackers can find valid paths that normal monitoring never mapped. The result is hidden exposure, inconsistent authorization and a larger attack surface than the security team believes exists.

Q: Why do stolen API credentials create such a fast-moving breach path for modern applications?

A: Stolen API credentials create fast-moving breach paths because they often grant immediate, privileged access without a second trust decision. Attackers can use them before defenders detect the leak, especially in machine-to-machine environments where traffic volume is high and monitoring is difficult. Once a valid token, key, or certificate is exposed, the attacker can act like an authorized caller until the credential is revoked or expires.

Q: How should security teams detect API reconnaissance that looks like normal traffic?

A: Security teams should look for correlated patterns across many small API events rather than judging each request alone. Attackers often probe user IDs, object IDs, and privilege boundaries in ways that appear ordinary in isolation. Effective detection needs baseline behavior, context across time, and the ability to separate user mistakes from malicious probing before exploitation succeeds.

Q: What should organisations do first to reduce API attack exposure?

A: Start with a complete inventory of every exposed API, then assign ownership and remove or retire endpoints that no longer serve a business purpose. Without that baseline, later controls such as authentication hardening, anomaly detection and policy enforcement will always miss part of the environment. Discovery comes before durable governance.

Technical breakdown

Why API attacks bypass traditional pattern-based detection

API attacks often succeed without obvious exploit signatures because they target the logic of the application behind the endpoint. Rather than dropping malware or forcing a noisy login failure, an attacker can enumerate fields, alter parameters, or chain legitimate-looking requests to expose data and functionality. This makes behaviour and context more important than payload signatures. In practice, security teams need to understand which API calls are normal, which data objects they touch, and which business actions they can trigger, because the exploit may be a valid request used in an invalid way.

Practical implication: tune detection around abnormal request sequences, not just malicious code patterns.

How shadow and zombie APIs become hidden attack paths

Shadow APIs are interfaces that exist but are not fully inventoried or governed, while zombie APIs are endpoints that should have been retired but remain reachable. Both create a discovery problem before they become a protection problem. If the security team does not know an API exists, it cannot assign ownership, apply policy, or monitor access patterns consistently. The article’s point is that API sprawl turns governance failure into exposure, especially when third-party or open-source integrations multiply the number of undocumented interfaces. Continuous discovery is therefore part of control, not a separate hygiene task.

Practical implication: treat continuous API discovery as a prerequisite for access control and exposure management.

Why stolen API credentials are an identity governance issue

API keys and related tokens are credentials, not just configuration artefacts. When attackers gain a privileged key through social engineering or exposure, they can impersonate legitimate users or services and move through the API as if authorised. That breaks the assumption that authentication alone proves trust, because the credential may be valid even when the actor is not. The governance problem is lifecycle control: issuance, scoping, rotation, revocation and owner accountability. Where machine credentials are reused or left standing too long, the API becomes a durable access path rather than a controlled entry point.

Practical implication: govern API keys with the same rigor as privileged human access, including rotation and revocation.

Threat narrative

Attacker objective: The attacker seeks to use trusted API pathways to exfiltrate data, impersonate legitimate users and abuse application functionality without triggering conventional perimeter controls.

1. Entry begins with reconnaissance against exposed, shadow or poorly governed APIs, where the attacker probes endpoints for business logic and access weaknesses.
2. Credential access follows when stolen API keys, tokens or privileged service credentials are obtained through social engineering or leakage.
3. Impact occurs when the attacker uses legitimate-looking API access to impersonate users, extract data or manipulate application functions at scale.

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.
• 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 governance has become an identity control problem, not only an application security problem. Once keys, tokens and service credentials are the mechanism of access, the question is who or what is allowed to act through them and for how long. That places API inventory, credential scope and revocation into the same governance conversation as PAM and NHI lifecycle control. Practitioners should treat every externally reachable API as an identity-bound access surface.

Shadow API exposure creates governance debt that traditional testing cannot clear. Pen testing can validate known endpoints, but it cannot compensate for undocumented interfaces that are still live in production. This is why discovery has to be continuous and tied to ownership, risk rating and retirement. The named concept here is API governance debt: the accumulation of unmanaged interfaces and credentials that outpaces review processes. Practitioners should reduce that debt before trying to optimise detection.

Business logic abuse is the hardest API risk to govern because the request is often valid even when the intent is not. That means control owners must focus on context, sequence and entitlement, not only authentication success. OWASP API Security Top 10 remains relevant because the most damaging failures are often broken authorisation, unrestricted business flows and insecure API inventory. Practitioners should align API policy with what the business action should permit, not just what the endpoint accepts.

Stolen credentials turn API governance into a privileged access problem the moment service accounts or human-issued keys are reused. A valid token can outlive its intended purpose, especially when rotation, owner assignment and offboarding are weak. That is where NHI controls matter most, because machine access without lifecycle governance becomes a standing trust channel. Practitioners should close the gap between authentication and governance by binding every API credential to an accountable owner and an expiry discipline.

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 security is converging with identity governance because the control point is no longer just the endpoint, it is the credential and the entitlement behind it. When machine access is opaque, teams inherit the same problem NHI programmes face: they cannot govern what they cannot inventory. A live API register, linked to owners and expiry rules, becomes the minimum viable control plane for exposure reduction.

API governance debt: unmanaged endpoints, undocumented integrations and stale credentials accumulate faster than manual review cycles can resolve them. That debt raises the probability that a valid request will produce an invalid business outcome. Security teams should therefore measure discovery freshness and credential ageing as first-class risk indicators.

According to the 2024 State of Secrets Management Survey, secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%). That ranking helps explain why API credential lifecycle controls so often lag the speed at which integrations are created.

For practitioners

• Inventory every exposed API continuously Build a live register of public, partner and internal APIs, then tie each one to an owner, data classification and retirement date so shadow and zombie endpoints do not remain outside governance.
• Bind API credentials to lifecycle controls Apply issuance, scoping, rotation and revocation rules to API keys and tokens so a stolen credential cannot remain valid after its original purpose has passed.
• Test for business logic abuse paths Review whether legitimate API calls can be chained, replayed or parameter-tampered into unauthorised actions, especially where the request format looks normal but the outcome is not.
• Prioritise API access policy over endpoint count Measure whether each API can be reached only by the intended identity, service account or integration partner, then tighten permissions where broad access masks real usage patterns.

Key takeaways

• API attacks often work because the request is legitimate but the purpose is not, which makes governance and authorisation more important than signature matching alone.
• Shadow APIs, zombie endpoints and reused credentials expand exposure faster than most manual review processes can track, creating a hidden attack surface.
• Continuous discovery, credential lifecycle control and business-logic testing are the controls most likely to reduce API abuse before it becomes data loss.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• API Credential Lifecycle: The API credential lifecycle is the full journey of a secret used to authenticate software to an API, from creation to retirement. It covers issuance, storage, rotation, use, monitoring, revocation, and deletion. Strong lifecycle control reduces exposure from leakage, stale access, and unauthorized reuse across systems and environments.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.

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.