To test for skipped steps, map each step in the flow, then send the request for a later step without completing the earlier ones. The server should refuse every time. Test with a valid session, repeat with an expired one, and record whether the system fails open, denies access or returns an error.
Why this test matters
Multi-step flows such as checkout, signup, password recovery and approvals often check rules in the user interface only. The browser shows step two after step one, so developers assume nobody reaches step three directly. An attacker does not use the browser's route.
OWASP's testing guide poses the question exactly: if authentication expects steps one, two and three in order, what happens when a user goes from step one straight to step three? Does the application fail open, deny access, or return an error?
Set up
- Two test accounts, a normal user and, if relevant, an admin.
- A tool that can replay and edit requests, such as a proxy or a command line client.
- A written list of the steps and what each step is supposed to establish.
- A clean test environment with fake data.
The checklist
- Record every request in the happy path. Note the endpoint, method and any token or hidden field that links steps.
- For each step N, try calling it in a fresh session without steps before it.
- Try replaying step N after the flow is finished.
- Try repeating step N twice in a row.
- Try changing values between steps: price, quantity, recipient, role.
- Try using a token from one account in another account's flow.
- Try going backwards: complete step 3, then call step 2 again.
- Try letting the session sit idle past its timeout, then continue.
Expected results
| Attempt | Safe result |
|---|---|
| Call step 3 first | Refused, nothing created |
| Replay a finished step | Refused or idempotent, no second effect |
| Repeat a step | Same outcome as once, no double charge |
| Change a price mid flow | Server uses its own price |
| Use another account's token | Refused |
| Go back a step | State stays consistent |
The OWASP guide gives matching examples: returning to a summary page in a valid session to change an item's price before completing a purchase, and cancelling a loyalty transaction after points were added.
Recording defects
For each failure write the sequence, the account used and what was created or changed. Mention the rule that should have stopped it. Use a private ticket, as it describes a working abuse path.
Turning it into automation
Once you know the answers, automate the stable ones: an integration test that calls the later step directly and asserts a refusal. Keep the list of steps next to the test so new steps are added when the flow changes.
Some checks, like timing or parallel replay, may stay manual or need dedicated tooling. That is fine. Note them in the release checklist.
What good looks like
The server keeps its own record of progress and checks it on every request. It does not trust hidden fields or client flags. When you remove a step, the flow stops there.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which checks a scan can run by itself, then add the flow rules only your team knows.
Safeguard offers a free scan for dependency findings. Flow rules remain your own tests.
Quick check
Is a skipped step test the same as a penetration test?
No. It is a focused functional check that QA can run. A penetration test covers far more ground.
Do I need production access to run it?
No. Use a test environment with fake accounts and data.
Sources
Last reviewed: 19 October 2026.
