A fix must also preserve what works.

Describe two workflows

Before the change, describe the operation that must be refused and the legitimate workflow that must remain possible. For each, identify the actor, resource, state and expected decision. Apply authorisation checks on the server, even if the interface already hides a button.

Read back the resulting state

After the fix, replay both workflows and inspect the stored result. A successful HTTP response or confirmation screen is not sufficient evidence that a business rule was followed. When a material input changes, the validity of an earlier approval must be reconsidered.

Keep a useful record

Record the scope, steps, expected and observed results, tested version and limitations. One passing scenario does not prove the absence of all vulnerabilities. Our laboratory case illustrates this distinction in a closed model.

Sources and further reading

• OWASP — Authorization Cheat Sheet ↗
• OWASP — Transaction Authorization ↗

These references inform the approach. They do not indicate HAIDRA.DEV certification or partnership.