Home / Knowledge hub / Workflow bypass
Knowledge hub
Workflow bypass
Skipping a required step, such as payment or approval, by calling a later one directly.
What it means
Workflow bypass is a business-logic flaw where a multi-step process can be completed without finishing every step. Checkout, onboarding, approval or verification is meant to run in order. The server accepts the final call without checking that the earlier ones happened.
The cause is that order is enforced by the screens, not the server. The interface shows step one, then step two, then step three. A person who sends the third request straight away is not stopped, because nothing on the server remembers where they should be.
Why it matters
The costs are the ones the skipped step was there to prevent: orders confirmed but never paid for, accounts active without verification, expenses paid without approval, content published without review. Each looks like normal use in the data, with one missing record.
It matters for compliance too. Controls like identity checks and separation of duties exist because someone relied on them. If the system lets the approval be skipped, the control is not real, whatever your policy says, and an auditor who tests it will find that out.
How it shows up
It appears in checkout flows that mark an order paid when the confirmation page is requested, sign-up processes where email verification is only a screen, approval chains where the last approver's endpoint does not check earlier approvals, and multi-step forms where each step trusts the data of the previous one.
The fix is to model the process as a state machine on the server: each record has a state, and each action is allowed only from specific states. Test by calling later steps directly, repeating steps, going backwards, and changing the identifier of the record between steps.
Questions people ask
Workflow bypass, answered
Is workflow bypass the same as broken access control?
They overlap. Access control asks who may do something. Workflow bypass asks when it may be done, and in what order.
A valid, fully permitted user can still perform a step they should not reach yet.
Why do front-end checks not work?
Because requests can be sent without the front end. A hidden button or a disabled next step is only a suggestion to a person using the interface.
The server has to refuse the call itself.
What is a state machine in this context?
A set of states a record can be in, such as pending, paid or shipped, and a list of allowed moves between them. An action is refused unless the record is in the right state.
It makes skipped steps impossible by design.
Can an automated scanner find it?
Rarely. A scanner does not know which steps your business requires, so it sees nothing wrong with a valid request.
Finding it needs someone who understands the process and tries the steps out of order.
How do we test for it?
Map the steps, then call each later step with a record that has not completed the earlier ones. Also repeat, reverse and interleave steps.
Check the outcome in the data, not only the response message.
Sources
Where this comes from
Related
Terms that sit next to this one
State machine abuse
Moving an order or account into a state the normal flow would never reach.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Forced browsing
Typing the address of a page you were never linked to and finding it opens.
Separation of duties
Splitting a sensitive task so no single person can complete it alone.
Parameter tampering
Changing values in a request, such as a price or an id, to alter what happens.
Can step three happen without step two?
We follow your multi-step flows and call steps out of order to see what the server allows. Findings are what we exploited, with the request and response that show it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.