Mobile device integrity / iOS & Android
App Attest vs Play Integrity: what a backend can verify
Both APIs help evaluate whether a mobile request comes from an expected app or environment. Neither proves that a signed-in user can access a particular resource. The backend still owns that decision.
By Jeffrey Monica · Original engineering reference
Compare the trust boundaries
These are design and test boundaries. A signal is useful only when your backend verifies it and applies an independent authorization policy.
| Decision | Apple App Attest (iOS) | Google Play Integrity (Android) |
|---|---|---|
| Evidence creation | Attest a device-held key and later send assertions signed by that key. The server saves verified key material. | Request an integrity token for a sensitive operation. The backend asks Google Play to decode and verify its verdict. |
| Bind the protected action | Use a fresh, one-time server challenge and place the relevant request data into the signed client data. | For standard requests, calculate a stable digest of the relevant action and compare it with the decoded requestHash. |
| Replay resistance | Verify and consume the challenge; enforce the monotonically increasing assertion counter per registered key. | Standard requests include automatic replay protection; requestHash is still required to bind the verdict to the intended action. |
| Authorization | A valid assertion does not establish a user session, tenant membership, or resource permission. | An acceptable integrity verdict does not establish object-level permission or user identity. |
| Failure handling | Handle unsupported devices, registration failures, key replacement, environment changes, and verification timeouts explicitly. | Handle token/API errors, missing or weak verdicts, and unsupported environments without treating a missing signal as positive proof. |
Start by separating three questions
App integrity asks whether the app instance or environment meets a trust policy. Authentication asks which user is requesting the operation. Authorization asks whether that user may perform this action on this object. These are different checks, even when the client packages them in one HTTP request.
A valid mobile integrity signal is additional evidence for risk decisions; it is not a replacement for session authentication, object ownership checks, or server-side input validation. Treat the entire client payload as untrusted input.
An implementation review checklist
Trace the complete request through the backend before declaring either integration effective.
Define the action
Write down the HTTP method, route, authenticated principal, tenant, resource identifier, and fields that actually affect the operation.
Bind evidence to the request
iOS: issue and consume a unique challenge and verify the assertion over expected client data. Android: use a canonical request digest in requestHash and verify the same digest server-side.
Verify with the platform trust model
iOS: validate App Attest attestation, application identity, saved public key and subsequent signature/counter. Android: obtain the decoded verdict from Google Play and evaluate app/device signals using your policy.
Authenticate separately
Check the session or token independently from the device evidence. A valid integrity response never logs a user in.
Authorize each object and field
Enforce tenant ownership, privileges, and allowed updates on the server for GET, PATCH, POST, PUT and DELETE as appropriate.
Make failure states observable
Capture reason codes, request IDs and signal categories without logging raw attestation payloads, secrets or sensitive request bodies.
What to test against a hostile client
First, replay an old assertion or reuse a consumed challenge. Next, bind valid evidence to a different amount, route, account, or object identifier. Finally, keep the evidence valid but request someone else's resource. All three must be handled intentionally; the final case is an authorization test, not an attestation test.
The browser-based ZombieMutex device-attestation lab models these decisions with synthetic inputs. It does not sign real tokens, call Apple or Google, or certify a production verifier. Follow Apple's and Google's documentation to implement the actual cryptographic or token-verification steps.
Try the related labs and articles
Primary references
These vendor and standards references describe actual platform/API behavior. The interactive labs linked above use synthetic evidence and must not be mistaken for production validation.
Public conversation / GitHub Discussions
Discuss this article
Public comments are being set up. There is no live comment feed yet, and this page will not load a third-party widget until the discussion repository is configured.
Send a private correction or question →