Transaction authorization

What it means

Transaction authorization confirms a specific sensitive operation rather than merely proving a general login. The user should understand the significant details being approved, and the approval must remain bound to those details. Changes to recipient, amount, or other security-relevant values require a fresh decision.

A practical example

A transfer service shows the intended recipient and amount before approval. The backend rejects attempts to modify those fields after approval and prevents the same authorization from being reused for a different transfer.

What to check

Separate login state from transaction approval. Bind approval to the intended operation, enforce state transitions on the server, and test modification, replay, expiry, and concurrent requests.

A common pitfall

An MFA prompt without the transaction details may approve identity without confirming the user's intended action. A generic confirmation token should not authorize arbitrary later operations.

Think it through

A recipient changes after the user approves a transfer. Is the earlier approval sufficient?

Answer: No. The approval must apply to the actual operation and its significant details.

Approval must describe the actual operation

A fictional supplier portal requires approval before changing bank details. The significant facts include the supplier, new account destination, and effective date. A generic 'confirm your identity' prompt does not necessarily show that the approver understood those facts. Design the approval screen around the action being authorized and keep the server's representation aligned with what was displayed.

The operation should follow a defined state machine. Draft details become a pending request, approval applies to that request, and execution consumes the approved version. If significant details change, the request returns to a state requiring a new decision. Merely storing an approved boolean beside editable fields can break that binding.

Concurrent requests and retries create additional cases. Two browser tabs might modify the same pending change, or a client may repeat an execution request after a network timeout. The server needs to prevent approval from being reused for a different operation and handle repeated execution safely according to the business design.

Test the state transition, not only the button

Using dummy supplier records, write the expected draft, pending, approved, and executed states. Identify which roles may move the request between them. Add attempts to edit the destination after approval, execute before approval, and reuse an already-consumed approval. Each should have an explicit expected result.

Logs should preserve the approved operation's identity and relevant audit trail while protecting sensitive account data. The strongest evidence is a reproducible relationship between what the user approved and what the server executed. This approach also helps legitimate users resolve mistakes because the application can explain which exact version received approval.

Related concepts

• Authorization
• Multifactor authentication
• Business logic vulnerabilities