ASVS 5.0 V2.3.5 requires that high value business logic flows need approval from more than one user, to prevent unauthorized or accidental actions. Examples are large money transfers, contract approvals, access to classified data and safety overrides. It is a Level 3 requirement.
Why it matters
One compromised or mistaken account should not be able to move a million dollars or switch off a safety interlock. A second approver turns a single point of failure into two, and gives you a record of who decided.
How to implement it
Model the action as a request that is created by one user and executed only after approval by a different one.
- The approver must not be the requester. Enforce it in code with an id comparison.
- Set the threshold in configuration, for example transfers above a stated amount.
- Bind the approval to the exact request: store a hash of the amount, target and parameters, and reject approval if they change afterwards.
- Expire pending approvals after a set time.
- Log request, approval, rejection and execution with user ids and times.
Require recent authentication for the approver, so a hijacked session cannot approve in the background.
How to test it
Try to approve your own request, approve twice with the same account, edit the amount after approval, and approve after expiry. Each must fail. Confirm the audit log shows both identities.
Beyond two people
For the highest value actions, require approvers from different teams, or from different roles, so that one manager and their direct report cannot approve each other. Revoke pending approvals when either user is deactivated, and record the reason for every rejection.
Common mistakes
- Two approvers who share a role and a login.
- Approval of a request id that can still be edited.
Quick check
Why bind the approval to a hash of the request?
So the requester cannot change the amount or destination after the approver has said yes.
