API security testing is now an identity and supply chain problem

At a glance

What this is: API security testing is about finding flaws in interfaces that connect systems, and the article argues that broken authentication, injection, exposed keys, and weak access controls are the main risks practitioners must test for.

Why it matters: It matters because APIs often sit on the boundary between application security and identity governance, so IAM, PAM, and AppSec teams need shared controls for authentication, authorization, secrets, and least privilege.

By the numbers:

• The MOVEit data breach impacted more than 2,500 organizations and over 67 million people worldwide.
• Researchers were able to identify 1,567 breach notifications related to MOVEit.
• T-Mobile: Personal data of 37 million customers was scraped by attackers exploiting an API vulnerability in 2023.
• The OWASP API Security Top 10 was launched in 2019, and updated in 2023.

👉 Read OXSecurity's full guide to API security testing and breach prevention

Context

API security testing is the discipline of checking whether an interface can be abused to read, write, or move data in ways the application owner never intended. In this article, OXSecurity frames APIs as a central attack surface because they concentrate authentication, authorization, and data access in a form that is easy for both developers and attackers to use.

The identity connection is direct: APIs are frequently authenticated with keys, tokens, OAuth grants, or service credentials, so broken API controls become identity failures as much as application flaws. That makes this topic relevant to IAM, PAM, and NHI governance teams, especially where third-party integrations, secrets sprawl, and delegated access are already widening the blast radius.

Key questions

Q: What breaks when API authentication is correct but authorisation is weak?

A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement. That failure usually appears as BOLA, broken function-level access, or mass assignment. Security teams should test whether an authenticated caller can move from one object, record, or action to another without additional approval.

Q: Why do APIs turn secrets into a governance problem?

A: Because API keys, tokens, and certificates are credentials that can outlive the systems and people that created them. If they are hardcoded, leaked, or left unrotated, the API remains usable even after code changes or team changes. That makes lifecycle control, storage, and revocation part of identity governance, not just development hygiene.

Q: How do security teams know whether API rate limiting is working?

A: Look for reduced scraping, fewer bursts of automated calls, and fewer large exports from endpoints that should only support ordinary business use. If attackers can still enumerate records or generate high-volume requests without friction, the control is too loose. Effective rate limiting should change attacker behaviour, not just reduce server load.

Q: Who is accountable when a partner API exposes customer data?

A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.

Technical breakdown

Why broken authentication and authorization dominate API risk

APIs fail differently from web pages because they are designed for machine-to-machine trust. When authentication is weak, an attacker can impersonate a legitimate caller with a stolen token, API key, or session. When authorization is weak, the caller is authenticated but can still access objects, functions, or records it should never reach. Broken object-level authorization and broken function-level authorization are especially dangerous because they let attackers enumerate resources and move laterally through business logic rather than breaking encryption. In practice, these flaws are often easier to exploit than traditional code vulnerabilities because the attacker only needs to understand how the interface behaves.

Practical implication: Test authentication and authorization separately at every sensitive endpoint, not just at login or gateway layers.

How injection, mass assignment, and SSRF become API abuse paths

API-specific injection occurs when user-controlled input is passed into queries, commands, or backend requests without proper validation. Mass assignment happens when the API accepts fields the developer never intended to expose, allowing attackers to overwrite privileged attributes such as roles or account state. Server-side request forgery is dangerous in API environments because a request parameter can be turned into a backend fetch to internal services, metadata endpoints, or admin interfaces. These are not abstract coding bugs. They become breach enablers when APIs sit between public callers and trusted internal systems, especially in cloud and microservice architectures.

Practical implication: Validate inputs, restrict writable fields, and block backend request paths that can reach internal-only services.

Why rate limiting and secret hygiene are security controls, not performance extras

Rate limiting limits how often an API can be called, which reduces brute force, scraping, denial of service, and high-volume exfiltration. Secret hygiene matters because API keys, tokens, and certificates are credentials, not configuration details. If they are hardcoded, leaked, or long-lived, the API may be technically authenticated while still being operationally exposed. In modern environments, the real control boundary is often the combination of credential lifecycle, endpoint monitoring, and request throttling. Without those controls, the API becomes a durable path into sensitive data and downstream systems.

Practical implication: Treat rotation, throttling, and secret storage as one control set, and review them together during API security testing.

Threat narrative

Attacker objective: The attacker aims to use a trusted API path to steal data, harvest credentials, and expand access into adjacent systems without triggering normal user-facing controls.

1. Entry occurs when attackers exploit a vulnerable API endpoint, often through SQL injection, broken authentication, or exposed credentials that allow them to call the interface as if they were a trusted client.
2. Escalation follows when authorization checks fail, letting the attacker enumerate objects, pull file data, abuse administrative functions, or pivot into connected systems through the API.
3. Impact arrives through unauthorized data extraction, credential theft, or broader supply chain exposure, as the same interface that supports business workflows becomes the path for mass compromise.

NHI Mgmt Group analysis

API security is now an identity control problem as much as an AppSec problem. The article is right to centre authentication, authorization, and least privilege because those are identity decisions expressed through software interfaces. Where APIs are protected only by valid credentials, organisations often confuse successful authentication with safe access. That confusion is especially costly when service accounts, tokens, and third-party integrations are the real callers. Practitioners should govern APIs as identity-bearing entry points, not just as code paths.

Broken API authorisation is a governance failure, not a coding nuisance. BOLA, mass assignment, and unrestricted resource access are all signs that the application has not mapped identity to object-level entitlement correctly. In identity terms, the interface has no reliable way to prove that the caller should see a specific record, action, or workflow. That is why API testing must be tied to access modelling, not just vulnerability scanning. Practitioners should align API tests with entitlement review and business object ownership.

API secrets create a hidden NHI surface that many programmes still under-govern. API keys, OAuth tokens, and certificates are non-human identities in operational form, even when teams treat them as implementation details. A leaked key can be more durable than a compromised user session because it may survive code changes, ownership changes, or offboarding. Credential persistence window: this is the gap between credential creation and effective revocation, and it is where API risk becomes persistent. Practitioners should manage API credentials with the same lifecycle discipline they apply to privileged accounts.

Supply chain exposure makes API testing a third-party governance issue. The article’s MOVEit example shows how indirect compromise can spread through vendors, integrators, and downstream consumers. That means API security testing needs to extend beyond owned code into partner dependencies, exposed integrations, and transfer points that trust external systems by default. The governance lesson is simple: if an API can be reached by a third party, it can also be abused by a third party. Practitioners should include supplier access in API risk reviews and offboarding checks.

What this signals

Credential persistence window: API programmes fail when the lifetime of keys, tokens, and certificates exceeds the lifetime of the access they were meant to represent. The practical signal is simple. If credential revocation cannot be verified quickly, the API estate is functioning like a standing privilege system, and that is an identity governance problem as much as an application problem.

API testing programmes should now be measured against object-level entitlement coverage, not just vulnerability counts. A low scan volume with incomplete authorisation testing gives false confidence, especially where business logic, partner integrations, and bulk export endpoints create the real exposure. Teams should align AppSec results with IAM evidence, secret inventory, and supplier access reviews.

The forward indicator for mature programmes is not the number of APIs discovered but the number of high-risk APIs tied to explicit owners, monitored credentials, and tested least-privilege rules. Where that linkage is missing, the interface layer becomes a shadow identity layer. That is the condition most likely to turn routine API use into breach-scale exposure.

For practitioners

• Map every sensitive API to an identity owner Assign a named owner for each API, then record which human, service, or third-party identities can call it and what business objects they can reach. Use that inventory to drive access reviews, not just code review.
• Test object-level authorisation separately from authentication Build test cases for BOLA, mass assignment, and function-level access so you verify that authenticated callers still cannot overreach their intended scope.
• Treat API keys and tokens as managed NHI credentials Store them in controlled secret systems, rotate them on a defined schedule, and revoke them when integrations are retired or vendors are offboarded.
• Apply rate limiting to exfiltration-sensitive endpoints Put tighter throttles on search, export, download, and bulk-read endpoints so automated scraping and high-volume abuse are constrained before data loss occurs.
• Include third-party API paths in supplier risk reviews Validate external integrations, inherited API permissions, and offboarding steps for vendors that depend on your APIs or expose theirs into your environment.

Key takeaways

• API security testing is really about proving that authenticated callers cannot exceed intended access, especially where business logic and object-level permissions are involved.
• Leaked keys, long-lived tokens, and weak rotation turn APIs into durable identity paths, which is why credential lifecycle control belongs in the API risk model.
• The practical response is to combine AppSec testing with IAM ownership, supplier governance, and secret management so interface security is enforceable end to end.

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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Mass Assignment: An API weakness where user-controlled input is mapped directly onto internal objects, allowing an attacker to set fields that should have remained hidden. It becomes dangerous when privileged attributes such as roles, approval state, or ownership can be overwritten through the request body.
• 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.

What's in the full article

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

• Step-by-step examples of API security testing methods, including SAST, DAST, and SCA in the SDLC.
• Specific API vulnerability categories such as BOLA, SSRF, and unrestricted resource consumption in more depth.
• Comparisons between REST, SOAP, and GraphQL security controls for different deployment patterns.
• The article's own framing of API security tooling, discovery, and runtime monitoring.

👉 OXSecurity's full article covers testing methods, API risk categories, and control options in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle practices that support stronger access control. It gives security practitioners a shared language for governing credentials and privileges across modern programmes.