Insufficient workflow validation

This vulnerability demonstrates insufficient workflow validation, where the application fails to enforce the correct sequence of actions during the purchasing process. Instead of verifying that each critical step in the workflow has been legitimately completed, the application trusts that users will follow the intended process and allows direct access to later stages without confirming earlier requirements.

The issue becomes visible when observing the checkout process through Burp Suite. After logging in and purchasing an item that can be afforded with the available store credit, the request flow reveals multiple steps involved in completing an order. When the user places the order, the application sends a POST /cart/checkout request, which processes the payment and then redirects the user to an order confirmation page. The confirmation page is accessed through a request such as:

GET /cart/order-confirmation?order-confirmation=true

Under normal conditions, this page should only be accessible after a successful checkout operation. It is expected to serve purely as a display page confirming an already completed transaction. However, testing shows that this endpoint performs more than just rendering confirmation details.

After sending the confirmation request to Burp Repeater for further analysis, the attacker adds a high-value item, such as the leather jacket, to the cart—an item that exceeds the available store credit. Normally, attempting to purchase this item through the proper checkout flow would fail because the user lacks sufficient funds.

Instead of following the intended process, the attacker simply replays the previously captured confirmation request:

GET /cart/order-confirmation?order-confirmation=true

The application incorrectly treats this request as sufficient to finalize the purchase. The expensive item is ordered successfully without triggering payment processing or deducting the cost from the user’s store credit.

This confirms that the application does not validate whether the required checkout step has been completed before processing the order confirmation. In other words, the system assumes that because the confirmation endpoint is reached, payment has already been handled. There is no server-side verification of transaction state, payment status, or session-based workflow progression.

The root cause of this vulnerability is missing server-side state validation. The application does not maintain or verify a secure order state machine. Instead of checking whether:

• payment was successfully processed,

• sufficient store credit was available,

• the current cart matches the previously validated order,

the backend simply processes the confirmation request independently.

A secure implementation would enforce strict workflow sequencing by maintaining server-side transaction states. For example:

• cart_created

• payment_pending

• payment_completed

• order_confirmed

Each endpoint should verify that the request is valid for the current state before proceeding. The confirmation page should only display information and never trigger order completion logic by itself.

This vulnerability highlights an important lesson in web application security: sensitive workflows must be enforced server-side, not assumed based on navigation paths or client behavior. If applications fail to validate state transitions, attackers can skip required steps and abuse business processes for financial gain or unauthorized actions.