What You See Is What You Sign means the user approves the exact amount and recipient that the server will execute, and any change after approval invalidates it. Build transaction authorization so the server generates and stores the transaction data, each credential works once, and execution verifies the approval.
What the principle requires
The OWASP Transaction Authorization cheat sheet says an authorization method must let a user identify and acknowledge the data that matters for a transaction. For a wire transfer, that means the target account and the amount. Developers cannot assume the user's device is secure, so the data shown for approval should come from a trustworthy path.
Rules a payments team can test
| Rule from the guidance | What to test |
|---|---|
| Enforce authorization on the server | Remove or alter client parameters and confirm the transfer is refused |
| Generate verification data on the server | The amount and recipient shown at approval come from stored server state |
| Each credential works once | Replaying an approval code fails |
| Credentials expire quickly | A code used after the window fails |
| Method is enforced by the server | A client cannot downgrade to a weaker method |
| Steps happen in order | Skipping from entry straight to execution fails |
| Final control gate before execution | Execution checks that this exact transaction was authorized |
| Brute force protection | After a set number of failures, the authorization restarts |
The attack to design against
The guidance describes a time of check to time of use problem. Malware or an attacker replays the first step in the background, overwrites the transaction details with a fraudulent transaction, and a poorly built process authorizes the first transaction but executes the second.
The defence is stated plainly. If transaction data is modified after the user enters it, invalidate any previously entered authorization data and reset the process. Treat any attempt to modify data after entry as an attack to log, monitor and investigate.
Do not reuse login for approval
The cheat sheet warns against requiring the same actions for login and approval. If both use the same one time code, malware can show a false error after login, get the user to repeat the step, and use the second code to authorize a fraudulent transaction. Use a different method or a different mode for approval, and show a clear message about what the user is signing.
One time and short lived
Two separate properties matter. Credentials should be valid for a limited window between challenge and completion, which also helps against resource exhaustion. And each credential should be unique per operation, for example with a timestamp, sequence number or random value in the signed transaction data. The guidance goes further and says to accept each authorization credential a single time, atomically checking that it is unused and marking it used, with state shared across all accepting servers. A payments system with multiple application servers must not check usage in local memory.
A build checklist
- Store the pending transaction on the server with an identifier, and display from that record.
- Bind the approval to a hash of the amount, recipient and currency.
- Make approval single use and time limited.
- At execution, re-read the stored transaction and verify the approval matches.
- Log creation, approval, any modification attempt and execution with the same identifier.
- Write tests for replay, modification after approval, skipped steps and method downgrade.
What the guidance leaves to you
OWASP says each application owner decides which transactions need authorization, based on risk analysis and other safeguards. A small internal transfer and a large external payout may deserve different treatment. It also recommends cryptographic operations to protect integrity, confidentiality and non-repudiation, and says that provisioning and protecting device signing keys during pairing is critically important.
Where Safeguard fits
Safeguard does not implement your authorization flow. Its dependency scanning and reachability analysis cover the libraries beneath it, and its policy gates add checks at the pull request. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is an SMS code enough for approving a transfer?
It is one method named in the guidance. Whatever method you use, bind it to the transaction details, make it single use and time limited, and enforce it on the server.
What if the amount changes after approval?
Invalidate the earlier approval and restart authorization, and log the attempt for investigation.
Sources
Last reviewed: 19 October 2026.
