API Request Combinations

Expanded Definition

API request combinations describe a testing approach in which individual API calls are chained, sequenced, or varied together to expose behaviour that a single request can miss. The key idea is not volume, but interaction: one request may create state, a second may reuse that state, and a third may reveal an authorization or validation gap that only appears in context.

This matters because many APIs behave safely when viewed endpoint by endpoint, yet fail when business logic, session state, object ownership, or workflow order are exercised together. The term sits within application security and API security, not as a vulnerability by itself, but as a method for finding weaknesses such as broken object-level authorization, workflow bypass, or inconsistent validation. A common boundary mistake is to treat every multi-step sequence as suspicious; in practice, legitimate user journeys and attacker-driven abuse can look similar, so the assessment value comes from understanding whether the sequence changes security-relevant behaviour.

Examples and Use Cases

In practice, API request combinations appear wherever security depends on order, state, or ownership. A single endpoint may look correct until it is tested as part of a realistic transaction chain.

• A user creates a resource, then retries the update call with a different identifier to see whether ownership checks still hold.
• An assessor sends a valid token to one endpoint, then reuses the same token across a second workflow step to test whether authorization is re-evaluated.
• A client submits a normal payment or approval sequence, then rearranges the calls to check whether the backend accepts an out-of-order state transition.
• A tester combines search, export, and detail-view requests to see whether one request leaks identifiers that make the next request more powerful.

These combinations are especially useful when APIs expose partial objects, multi-step approvals, or asynchronous processing. The tradeoff is that more realistic testing takes more setup and produces more ambiguous results, because some failures reflect business-rule design rather than a direct security defect. Still, when the goal is to understand how the system behaves under genuine workflow pressure, combination testing is often more revealing than isolated endpoint checks.

Security Implications

The main security value of API request combinations is that they expose flaws hidden by single-request testing. A backend may enforce validation on one call but fail to preserve that same control when the request is repeated, reordered, or paired with another valid request. That can lead to broken access control, privilege drift within a session, inconsistent object state, or unintended disclosure of data that is only reachable after a seemingly harmless first step.

For defenders, the practical concern is blast radius. A flaw that looks minor in one endpoint can become more serious when chained with another permitted action, because the attacker no longer needs malformed input. They can use normal requests in a sequence that the system was never meant to authorize as a whole. The observable symptom is often a workflow that succeeds even though the user should not have been able to reach that state through the public API.

This is why security assessments should examine not only whether each request is valid, but whether the combined transaction remains valid when state, timing, and identity context change.

Domain and Governance Relevance

API request combinations matter most in application security governance because they test whether business controls survive real user behaviour rather than only unit-level checks. The subject is broader than one endpoint: it concerns whether the API enforces state transitions, authorization boundaries, and object ownership consistently across a workflow.

Where APIs underpin customer actions, integrations, or delegated automation, combination testing becomes a control assurance activity as much as a vulnerability discovery method. It helps answer whether the security model is embedded in the workflow itself or only in isolated handlers. In environments with machine-to-machine traffic, this also intersects with identity governance because a valid client credential may still be over-empowered once requests are combined in sequence. In that sense, the issue is less about the credential alone and more about whether the API trusts each request independently instead of evaluating the whole action path.

For NHIMG’s specialist lens, the important distinction is that the primary subject remains API behaviour. Non-human identity concerns become relevant only when request combinations reveal that automation, service credentials, or delegated access can be used to complete an unauthorized workflow.

Related resources from NHI Mgmt Group

• 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?
• What breaks when an authenticated user can modify privilege-bearing API fields through a normal update request?