API Request Impersonation

What API request impersonation means

API request impersonation happens when an attacker makes an API call that is accepted as though it came from another user, service, or client. The security issue is not the request itself, but the broken trust boundary that lets a forged or replayed call inherit someone else’s authority.

This is closely related to broken authentication and weak request integrity. If tokens, signatures, headers, or session bindings are not validated strongly enough, the API can no longer reliably distinguish the real caller from the impersonated one.

How API request impersonation works

Impersonation usually depends on some form of trust reuse. A stolen bearer token, replayed session, forged forwarding header, or copied client assertion can let a request arrive with a believable identity context even when the attacker never legitimately authenticated.

The abuse often succeeds because the API trusts metadata more than proof. In practice, that can mean the service accepts claims about who sent the request without verifying whether the request was bound to the original client, device, channel, or session state.

Impersonation can be especially damaging in delegated or service-to-service designs, where on-behalf-of calls are normal. The same design that enables automation and integration can also give an attacker a clean way to blend in if token scope, audience, expiry, and replay protection are too weak.

For deeper background on the API-side failure patterns, see the OWASP API Security Top 10, which frames the broader class of broken authorisation and API trust failures.

Why it is dangerous for access control and trust

Once a request is accepted under the wrong identity, normal access controls can be bypassed cleanly. That can expose data, trigger privileged functions, create fraudulent transactions, or let an attacker act as a high-trust service that downstream systems assume is safe.

The most important consequence is that the API may preserve the impersonated caller’s privileges, not the attacker’s actual privileges. In other words, the security boundary moves from “who sent the request” to “what the request claims to be,” which is a much weaker position unless the protocol enforces strong proof of origin.

In cloud and enterprise API environments, this can become a lateral movement path as well as an access-control issue. A compromised token or session can be reused against multiple endpoints until the trust relationship is detected and revoked.

What defenders should verify and harden

API request impersonation should be assessed by tracing where caller identity is established, propagated, and revalidated. Teams need to know which headers, tokens, gateways, proxies, and downstream services influence identity decisions, and whether any of them can be spoofed or replayed.

Controls should focus on binding requests to a real authenticated context, not just accepting identity claims at face value. Strong token validation, audience and issuer checks, replay resistance, short-lived credentials, and careful separation of user and service identity all reduce the chance that a forged request will be accepted.

For API teams that want a control-oriented baseline, NIST SP 800-228 API Protection for Cloud-Native Systems Guide is a useful companion for authentication, gateway patterns, and per-request authorisation.

If the impersonation path involves a specific token exchange or delegated call flow, the relevant protocol guidance is RFC 8693: OAuth 2.0 Token Exchange, which defines how delegation should work when one identity acts on behalf of another.

NHIMG’s Pretexting Guide is also useful where the attack begins with caller deception or impersonation of a known person or support channel rather than pure protocol abuse.

Detection and response after suspected impersonation

Detection starts with identity-sensitive telemetry: unusual token use, impossible travel between trust boundaries, repeated requests from the same credential across new sources, altered headers, or API calls that do not match the expected client behaviour. Logging should preserve enough context to reconstruct the request path, not just the final authenticated principal.

After suspected impersonation, responders should treat the affected credential, session, or client assertion as compromised until proven otherwise. That often means revoking tokens, invalidating sessions, rotating shared secrets or signing material where applicable, and reviewing whether downstream systems accepted the forged identity before containment.

Post-incident review should ask whether the compromise was caused by theft, replay, header forgery, or a design flaw in the trust model. That distinction matters because the fix may be different for each case, from stronger request binding to removing unsafe trust in upstream metadata.

Risk and Threat Considerations

API request impersonation is dangerous because it converts stolen or forged identity material into direct application trust. The attacker does not need to break the API itself if they can make the API believe the request belongs to someone else.

Failure mechanism: The API accepts identity claims, tokens, or headers without sufficient request binding, so a replayed or forged request inherits the target’s access and reaches protected actions or data.

Impact: The result can be unauthorised data access, fraudulent transactions, privilege misuse, service abuse, or lateral movement through trusted API paths.

Related resources from NHI Mgmt Group

• Who is accountable when a fake support bot or impersonation request causes a breach?
• What breaks when request size limits are missing from API governance?
• What do teams get wrong about reducing API request volume?
• How should security teams test API security when business logic depends on request order and timing?