Mobile App Attestation: Verify Genuine Apps and Devices Before Trusting Requests

Your API cannot tell from a request alone whether it came from your real app on a real phone or from a script replaying your app's traffic. Mobile app attestation closes that gap: the platform vouches, with hardware-backed cryptography, that a request comes from a genuine, unmodified build of your app on a genuine device, and your backend checks that proof before doing anything sensitive. This guide explains how Google's Play Integrity API and Apple's App Attest work, what each verdict does and does not prove, how to verify tokens on the server, how to roll enforcement out without locking out real users, and how to measure it. It is for mobile engineers, backend and API security teams, and fraud teams. General mobile hardening is covered in the Mobile App Security Guide; this page goes deep on attestation only. Platforms are listed alphabetically by vendor.

Key takeaways

• Attestation is a backend control. The app collects a signed statement from the platform; only your server's verification decides anything. Client-side checks alone can be patched out.
• Bind every token to the request. Use Play Integrity's requestHash or App Attest's clientDataHash over the request body and a server challenge, or an attacker can reuse a valid token for a different action.
• Verdicts are signals, not identities. A genuine device and app does not mean an honest user; combine attestation with account risk, rate limits and authentication.
• Unsupported devices are normal. Both platforms document cases where attestation is unavailable, so design a degraded path rather than a hard block.
• Roll out in observe mode first. Log verdicts for weeks, measure failure rates by device and OS version, then enforce on the highest-risk endpoints only.

What attestation proves and what it does not

Apple states the core problem plainly in its App Attest documentation: an app cannot rely on its own logic to perform security checks on itself, because a compromised app can falsify the results. Attestation moves the trust anchor off the device's software and onto a platform service and hardware-backed keys. OWASP's MASVS makes the same point from the other side: resilience controls such as platform integrity checks add defence in depth, but security must still rely on server-side validation, and the absence of these controls is not itself a vulnerability.

That last row matters for fraud teams. Attestation raises the cost of abuse from "write a script" to "acquire and operate real hardware", which removes most commodity bot traffic, but determined operators accept that cost. Pair it with the controls in the OWASP API Top 10 API6 Unrestricted Access to Sensitive Business Flows Guide and the Bot Management Guide.

Apple App Attest

App Attest is part of the DeviceCheck framework. The app uses the shared DCAppAttestService to create a hardware-based key that Apple's servers certify as belonging to a valid instance of your app.

1. Check support: read isSupported. Apple says not all devices can use the service and that the app should gracefully bypass it when unsupported, with the server no longer requiring assertions for that device. Apple lists action, extensible SSO and watchOS extensions as supported and all other extension types as unsupported, even if isSupported returns true.
2. Generate a key: generateKey returns a key identifier. Keys survive normal app updates but not reinstallation, device migration or restore from backup.
3. Attest the key: the server issues a one-time challenge; the app calls attestKey with a hash of it (clientDataHash). If Apple returns serverUnavailable, retry later with the same key; for any other error, discard the key and create a new one.
4. Assert on sensitive requests: generateAssertion signs a hash of the request with the attested key. Apple sets no limit on assertions per key but suggests reserving them for sensitive moments.

Server verification of the attestation object (from Apple's "Validating apps that connect to your server"): validate the certificate chain to Apple's App Attest root; recompute the nonce from the authenticator data and your challenge and compare it with the value in the leaf certificate extension; check that the key identifier matches the hash of the certificate's public key; check that the relying party ID hash equals the SHA-256 of your App ID (Team ID plus bundle ID); check that the counter is 0; and check the aaguid is the production value (appattest) rather than the development value (appattestdevelop) for production traffic. Store the public key against the user and device, and reject a key already associated with another user.

Server verification of assertions: verify the signature over the recomputed nonce with the stored public key, check the relying party ID hash, require the counter to be greater than the last stored value, confirm the embedded challenge matches the one you issued, then save the new counter. The monotonic counter is your replay defence.

Fraud signals: the attestation returns a receipt your server should store; Apple's "Assessing fraud risk" service uses it in server-to-server calls to return risk data. Apple advises against reusing one key for several users on a device, and against generating keys more than needed, because a low key count per device helps detect a single compromised device serving many remote users.

Availability: Apple's documentation directs apps with millions of daily active users to its "Preparing to use the App Attest service" guidance before ramping up attestation calls. See the iOS App Security Guide for wider iOS controls.

Google Play Integrity API

Play Integrity returns an encrypted, signed token that your backend sends to Google to decode. Google documents two request types; the standard request is the current recommended flow.

1. Warm up: call prepareIntegrityToken() with your Google Cloud project number and keep the returned StandardIntegrityTokenProvider in memory. Google says most warm-ups finish within 10 seconds and each app instance can prepare at most 5 times per minute.
2. Request a token on demand: compute a digest of the request being protected and pass it with setRequestHash() (maximum 500 bytes, never sensitive data in plain text). Without it, Google notes, the token is bound only to the device, not the request. Handle INTEGRITY_TOKEN_PROVIDER_INVALID by preparing a new provider.
3. Decode on the server: a service account with the playintegrity scope calls decodeIntegrityToken on playintegrity.googleapis.com. Check requestDetails first: package name, your recomputed requestHash and timestampMillis for freshness.
4. Rely on built-in replay protection: Google states that decoding the same standard token again returns cleared verdicts (empty device verdict, UNEVALUATED app verdicts), so a replayed token fails naturally.

Version nuance: on Android 13 and later, MEETS_STRONG_INTEGRITY requires device integrity plus security updates within the last year on all partitions; on Android 12 and lower it only requires hardware-backed boot integrity, so Google recommends also checking sdkVersion. On Android 13 and later the optional labels are only returned if the requesting app is licensed.

Availability: Firebase documents a Play Integrity limit of 10,000 calls per day on the standard tier when used through App Check; check your own quota in the Google Cloud console and request more before enforcing. See the Android App Security Guide for wider Android controls.

Designing the backend decision

The verdict is an input to a policy, not the policy itself. Decide per endpoint.

• Attest once, then issue a session credential: a common pattern is to attest at login or device enrolment, then bind your own short-lived token to the attested key or device record, and re-attest only for high-risk actions. This keeps quota use and latency down.
• Use a managed broker if it fits: Firebase App Check wraps App Attest, DeviceCheck, Play Integrity and reCAPTCHA Enterprise into one token that Google services and your own backend can verify. It simplifies integration; it also adds a dependency and its own token lifecycle to understand.
• Do not embed secrets as a substitute: API keys compiled into the app are extractable. Attestation is how you stop trusting a static key alone. See the API Key Management Guide.

Where identity fits

An attested app instance is effectively a non-human identity: a hardware-backed key, certified by the platform, that represents one installation. Treat it that way. Record which user and device each key belongs to, refuse a key already bound to a different user, revoke the device record on account recovery or reported theft, and expire it when the app is reinstalled. Attestation also strengthens OAuth flows for public mobile clients, which cannot keep a client secret: see the OAuth Attestation-Based Client Authentication Guide and, for the underlying hardware, the Hardware key attestation page.

Rolling out attestation

1. Threat model the endpoints. List which abuse you are fighting (credential stuffing, fake sign-ups, promo abuse, modified clients) and which endpoints it hits.
2. Integrate in observe mode. Ship the client SDK calls and server verification, but only log verdicts against each request. Apple's and Google's flows both fail in real-world conditions such as network errors and unsupported hardware.
3. Baseline for two to four weeks. Measure pass, fail and unavailable rates by OS version, device model, country and app version. Investigate any segment with an unusual failure rate before enforcing.
4. Enforce on one high-risk endpoint. Start with step-up rather than block. Watch support contacts and conversion.
5. Expand by endpoint and percentage. Use a server-side flag so you can widen or narrow enforcement without an app release.
6. Rollback: flip the server flag back to observe mode. Because enforcement lives on the server, rollback is instant; never ship client logic that blocks the user by itself.

Detection and measurement

• Verdict mix over time: share of requests by verdict; a sudden rise in UNRECOGNIZED_VERSION or missing device labels signals repackaged apps or emulator farms.
• Binding failures: count of requestHash, challenge or counter mismatches; these are attacks or bugs and should be near zero.
• Keys per user and users per key: rising App Attest keys per account, or one key used by many accounts, indicates abuse.
• Fallback-path volume: traffic taking the unsupported-device route; abusers migrate there once enforcement starts.
• Business outcome: fake account creation, promo abuse or fraud losses before and after enforcement.
• Collateral damage: legitimate users blocked or stepped up, from support tickets and conversion data.

Common failure patterns

• Checking on the device only. An app that reads its own verdict and decides locally can be patched to skip the check. Decisions belong on the server.
• Not binding the request. A token without a request hash or challenge proves the device once and can then front any request the attacker likes.
• Accepting development attestations in production. App Attest's appattestdevelop environment and test builds should never satisfy production policy.
• Hard-blocking every failure. Unsupported devices, custom ROMs and transient errors are real; blocking them causes support load and pushes users away without stopping farms of genuine phones.
• Ignoring the counter or freshness. Skipping the App Attest counter check or Play Integrity's timestamp check reopens replay.
• Treating attestation as authentication. A genuine app on a genuine phone can still be driven by a fraudster with stolen credentials; keep MFA and account risk scoring.

Framework mapping

Practitioner checklist

• List the endpoints and abuse cases attestation should protect, with a policy per risk tier.
• Verify all tokens on the server; never let the client decide.
• Bind each Play Integrity token with requestHash and each App Attest assertion with a challenge and request hash.
• Implement every App Attest server check, including the counter and production aaguid, and store the receipt.
• Check Play Integrity requestDetails, package name, signing certificate digest and timestamp before reading verdicts.
• Design and document the fallback for unsupported devices.
• Run in observe mode for at least two weeks, then enforce behind a server-side flag, starting with step-up.
• Monitor verdict mix, binding failures, keys per user and fallback volume, and confirm your platform quota.

Standards and references

• Apple Developer: Establishing your app's integrity
• Apple Developer: Validating apps that connect to your server
• Android Developers: Play Integrity API integrity verdicts
• Android Developers: Make a standard Play Integrity API request
• OWASP: Mobile Application Security Verification Standard
• OWASP: API Security Top 10 2023
• Firebase: App Check documentation

Related NHI Mgmt Group resources: Mobile App Security Guide · Mobile App Shielding and RASP Buyers Guide · Certificate Pinning · API Security Guide