Nonce handling in a classic Play Integrity request is a protocol responsibility. Specify who generates the value, which operation it belongs to and when it is consumed.
Evaluation approach
The server establishes a verification context and checks the nonce's relationship to the expected session and operation. Preventing used values from being accepted again belongs to the application protocol.
Application example
If the same evidence accompanies two transfer requests, the second request must not acquire new authorization. Design transaction records and verification records together.
Limits and considerations
Adding a random string does not solve replay if the server never tracks its use.
Nonce management belongs on the server
Nonce generation and acceptance conditions are part of the protocol. Bind the value to its session or operation, limit its lifetime and define replay behavior. Accepting any nonce supplied by the application weakens the binding check.
A successfully verified business request may arrive again because of a network retry. Preventing evidence replay and safely checking an operation's status are different requirements. Use server records to show the final transaction state instead of an ambiguous error.
Checks and decisions
- Define nonce lifetime
- Enforce single use
- Check transaction binding
Test challenge management with legitimate retries and stale evidence.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.