Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.

Overview

A later checkout endpoint can be invoked without completing the preceding payment state, and the server accepts the out-of-sequence transition.

Lab overview identifies `order-confirmed=true` as a client-reachable confirmation state not bound to successful payment.
Lab overview identifies `order-confirmed=true` as a client-reachable confirmation state not bound to successful payment.

Lab objective/setup

This intentionally vulnerable Academy exercise isolates insufficient workflow validation. The supplied accounts and endpoints are used to reproduce only the source note evidence for insufficient workflow validation; all request changes remain inside this Academy instance.

What I observed

The baseline capture for insufficient workflow validation establishes the intended request and response before any mutation. Subsequent replays isolate the input or state transition responsible for insufficient workflow validation, and the response evidence shows exactly when the lab accepts the unintended behavior.

Checkout of a cheap product establishes the normal payment request before order confirmation.
Checkout of a cheap product establishes the normal payment request before order confirmation.

Why it is vulnerable

The server validates individual requests but not the permitted state transition for the current order.

Walkthrough in the authorized PortSwigger lab

  1. Capture the baseline request for insufficient workflow validation and record the response that represents the intended lab workflow.
  2. Replay the recorded mutation that exposes insufficient workflow validation, keeping the session and other fields unchanged.
  3. Confirm the insufficient workflow validation signal in the response before applying the next source-documented operation.
  4. Complete the Academy objective using only the confirmed insufficient workflow validation behavior and the supplied synthetic account or product data.
Browser history shows `/cart/checkout` redirecting to `/cart/order-confirmation?order-confirmed=true` after a legitimate purchase.
Browser history shows `/cart/checkout` redirecting to `/cart/order-confirmation?order-confirmed=true` after a legitimate purchase.
Cart contains the Lightweight l33t leather jacket before navigating directly to the confirmation URL and skipping checkout.
Cart contains the Lightweight l33t leather jacket before navigating directly to the confirmation URL and skipping checkout.

Verification

The final capture shows the Academy marking the insufficient workflow validation exercise as solved after the documented request sequence. No testing was performed outside the isolated lab.

Order confirmation and Academy solved banner show the server accepted the client-selected confirmed state without payment.
Order confirmation and Academy solved banner show the server accepted the client-selected confirmed state without payment.

Impact and defensive lesson

The evidence demonstrates the concrete risk of insufficient workflow validation: a server-side trust decision can be bypassed through the exact input or workflow shown in this lab. For insufficient workflow validation, the server must enforce the exact invariant violated in the captured sequence and regression-test that mutation alongside the normal path.

References