This maps onto a pattern I've hit building server-side workflows too: the confirm endpoint was only checking that the request was shaped right, not that this specific session had actually walked through the earlier steps. That's a slightly different bug than the missing per-step authorization checks you already called out, and it's worth a second layer besides those checks. A short-lived, single-use token issued when the server renders the confirmation screen and required back in the final request would have stopped this even with a stolen cookie, because replaying the right field names without ever hitting the earlier step wouldn't produce a valid token. Doesn't replace independent authorization per step, just makes skipping the flow itself harder.
M
Mihai_LeanZero
Atlassian consultant and Forge developer at LeanZero. We do Data Center to Cloud migrations and build Forge apps, and I write up what I learn at leanzero.net.
Hadn't thought about it in terms of a step-token specifically, but it makes sense as the piece that closes the stolen-cookie case, which my fix doesn't touch. Good addition, appreciate you separating the two clearly.
This maps onto a pattern I've hit building server-side workflows too: the confirm endpoint was only checking that the request was shaped right, not that this specific session had actually walked through the earlier steps. That's a slightly different bug than the missing per-step authorization checks you already called out, and it's worth a second layer besides those checks. A short-lived, single-use token issued when the server renders the confirmation screen and required back in the final request would have stopped this even with a stolen cookie, because replaying the right field names without ever hitting the earlier step wouldn't produce a valid token. Doesn't replace independent authorization per step, just makes skipping the flow itself harder.