API security testing is now an identity and supply chain problem

At a glance

What this is: This article argues that API security testing must cover identity, secrets, and supply chain exposure, not just application flaws.

Why it matters: It matters because IAM, AppSec, and platform teams now have to govern API access as an identity problem as much as a code-quality problem.

By the numbers:

• The MOVEit data breach impacted more than 2,500 organizations and over 67 million people worldwide.

Context

APIs are the control plane for how modern systems exchange data, but that same reach makes them a security boundary as well as a development convenience. Once authentication, authorization, secrets, and third-party integrations converge on API access paths, the problem stops being purely application testing and becomes identity governance plus supply chain exposure.

For IAM and AppSec teams, the real issue is that APIs often inherit trust from multiple systems while hiding that trust behind automated calls and reusable credentials. That creates a gap between what developers intend, what the application enforces, and what defenders can actually verify across the software lifecycle.

Key questions

Q: What breaks when authentication and authorization are conflated in API security?

A: The system starts treating identity proof as if it were permission. That usually produces overly broad access, weak auditability, and credential handling that becomes the only guardrail. In practice, an authenticated caller may still be able to do far more than the business intended if authorization is not enforced as a separate decision.

Q: Why do third-party integrations increase breach risk in app ecosystems?

A: Third-party integrations expand the number of identities, tokens, and data paths that must be trusted. When one integration is misconfigured or overprivileged, attackers can move through API access rather than traditional endpoints. That makes visibility, access scoping, and anomaly detection critical, especially when business workflows depend on many connected services.

Q: What are the signs that API security controls are missing business logic abuse?

A: Common signs include unusual sequences of requests, repeated probing of endpoints, low traffic attacks that still change data or behaviour, and API activity that looks valid at the request level but abnormal in context. If security teams only see signatures or isolated calls, they may miss attack reconnaissance, parameter manipulation, and abuse that emerges over time.

Q: Should teams treat API security as part of IAM or AppSec?

A: Treat it as both, but with identity governance at the centre. AppSec covers testing and vulnerability management, while IAM controls who or what can call an API, under what scope and for how long. In modern environments, especially AI-enabled ones, separating those responsibilities leaves an accountability gap that attackers can exploit.

Technical breakdown

Why API testing is an identity problem

APIs do not just move data, they exercise identities. Authentication proves who or what is calling, authorization decides what it may touch, and secrets or tokens carry that authority into runtime. When those controls are weak, the API becomes a durable access path rather than a simple interface. That is why broken authentication, broken object-level authorization, and leaked API keys are so often part of the same incident pattern. The technical issue is not only whether the endpoint responds correctly, but whether the identity behind the call is constrained, scoped, and revocable in a way that matches the business flow.

Practical implication: test API identity controls as runtime access paths, not just as code-level checks.

How supply chain exposure expands API risk

Modern APIs rarely sit alone. They connect internal services, third-party vendors, mobile apps, and automation platforms, which means one exposed API can become a conduit into a wider software supply chain. If a vendor integration or downstream service trusts the wrong token, request, or object reference, the attacker does not need to break the whole application. They only need to inherit enough authority through a legitimate integration path. That is why API security testing has to include dependency visibility, third-party access scope, and the behaviour of interconnected services under realistic abuse conditions.

Practical implication: include third-party integrations and downstream trust paths in every API security test plan.

What makes API testing different from general appsec

General application security looks at broad software weaknesses, while API security has to inspect structured machine-to-machine interactions such as object access, request volume, and authorization boundaries. REST, SOAP, and GraphQL each change the shape of risk, but the core issue stays the same: the interface exposes business logic and data access in a way that is often more direct than a user interface. That means testing must cover object-level access, rate limiting, injection resistance, and the way API clients consume credentials. Where the interface is the product, authorization failure is often the breach condition.

Practical implication: build API-specific test coverage for authorization, abuse resistance, and credential handling.

Threat narrative

Attacker objective: The attacker wants to turn legitimate API trust into unauthorised access to data, credentials, or downstream services.

1. Entry occurs through a vulnerable API, exposed integration, or companion web application that allows attackers to reach privileged data-handling functions.
2. Credential access or privilege abuse follows when leaked API keys, weak authentication, or authorization flaws let the attacker act as a trusted caller.
3. Impact comes from unauthorised data access, credential exposure, or supply chain propagation through connected services and third-party integrations.

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 testing is now a governance problem, not just a scanning problem. The article shows that authentication, authorization, secrets, and third-party integrations all shape the real attack surface. That means the control objective is not only to find vulnerable endpoints, but to govern who or what can exercise API authority across the software lifecycle. Practitioners should treat API testing as part of identity assurance and supplier risk management, not a narrow AppSec activity.

API identity drift is the named concept practitioners should watch. APIs often inherit trust from reusable tokens, service accounts, and external integrations long after the original design assumptions have changed. Once that trust drifts away from the intended business flow, the API becomes a durable overreach mechanism rather than a controlled interface. The result is a governance gap that IAM and AppSec teams have to close together, because either discipline alone sees only part of the failure mode.

Third-party API exposure turns isolated defects into supply chain incidents. The article’s MOVEit discussion reinforces that indirect compromise can be as damaging as direct exploitation when downstream vendors, clients, or automation platforms inherit access. That pattern aligns with broader NHI and delegated-access concerns, because machine credentials often outlive the relationship that created them. Practitioners should assume integration paths can widen blast radius unless access scope is continuously revalidated.

Authorization quality matters more than endpoint count. A large API estate is not the primary risk by itself; the risk is that each route may carry business authority that defenders have not mapped cleanly. The key governance question is whether the API’s permission model matches the data and action it exposes. Teams that cannot answer that question are managing traffic, not access.

API security testing needs lifecycle ownership. The article makes clear that CI/CD is where many failures can be prevented, but the operational burden does not end at deployment. Discovery, rotation, logging, and integration review all matter because APIs are living trust relationships. The practical takeaway is that security leaders should assign ownership for API authority the same way they assign ownership for privileged access.

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.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: NHI Authentication Guide

What this signals

API identity drift: When service accounts, tokens, and partner integrations accumulate authority over time, API testing becomes a lifecycle problem rather than a point-in-time scan. Security teams should expect the real failure to appear where access scope no longer matches the business flow, not just where a scanner finds a flaw.

The practical implication for IAM and AppSec programmes is that API security evidence now needs to show who can call what, under which conditions, and through which external dependencies. That makes inventory quality, credential lifecycle, and authorization mapping first-class control signals, especially where machine identities back critical workflows.

For practitioners

• Map API identities to business authority Inventory which service accounts, tokens, and application identities can call each API and what data or actions each one can reach. Focus on the authority actually exercised at runtime, not the permissions that were intended at design time.
• Test third-party integrations for excess trust Review vendor and partner API connections for overbroad scopes, stale credentials, and object-level access that exceeds the integration’s purpose. Treat external calls as privileged pathways that can amplify a local defect into a wider compromise.
• Shift API testing left into CI/CD Automate authentication, authorization, input validation, and misconfiguration checks in the build pipeline so insecure changes are caught before release. Use manual verification for high-risk business flows and unusual edge cases that automation may miss.
• Harden secrets around machine-to-machine access Rotate API keys and other machine credentials on a fixed schedule, and revoke anything hardcoded, shared, or publicly exposed. Pair rotation with logging so leaked credentials can be detected and contained quickly.
• Baseline rate limiting and abuse controls Set request limits, throttling, and anomaly monitoring for APIs that expose sensitive data or high-value operations. This reduces scraping, brute force, and mass exfiltration even when authentication appears valid.

Key takeaways

• API security testing now has to cover identity-bound access paths, not just endpoint defects, because authentication and authorization failures can turn ordinary interfaces into breach paths.
• The MOVEit example shows how a single weakness can cascade through connected systems and affect more than 2,500 organizations and over 67 million people worldwide.
• Practitioners need shared ownership across IAM and AppSec, with lifecycle control over tokens, third-party integrations, and business-flow authorization.

Key terms

• API security testing: API security testing is the process of checking whether application programming interfaces can be abused, exposed, or manipulated by unauthorized users or software. It examines authentication, authorization, input handling, rate limits, data exposure, and business logic, using manual review and automated tests to find weaknesses before attackers or faulty integrations exploit them.
• 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.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Third-Party Integration Risk: Third-party integration risk is the chance that external services, APIs, or partner accounts create an unintended route into internal systems. These connections often bypass traditional perimeter assumptions, so they need the same identity, segmentation, and review discipline as internal access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners responsible for API-facing trust paths.It helps identity and security teams align access control, lifecycle discipline, and governance across the non-human identities that APIs depend on.