App Attestation Integrity
App attestation cryptographically proves to a server that the client is a genuine, unmodified build of the expected app, blocking modified clients and replayed tokens from tampered devices.
Definition
App attestation is a protocol where the client device signs a server-issued challenge with a hardware-backed key whose presence is proven to reside only in a genuine app build, so the server can distinguish a real client from a repackaged or scripted one before trusting its requests.
Context and scope
Applied in mobile banking, anti-fraud, and any API where the business risk of a modified client (rate limit evasion, abuse) justifies the integration cost.
Common misconceptions
- Attestation proves the user is legitimate — it proves the app build is genuine; a legitimate app on a compromised OS can still attest and then misbehave
- HTTPS makes attestation redundant — HTTPS protects the channel; attestation protects the endpoint identity, which TLS does not establish
Anti-patterns
- Attesting once at login and trusting the session forever, letting a tampered client take over the session afterward
- Treating attestation as a boolean gate rather than feeding the attestation freshness into risk scoring
Related concepts
Authoritative source
What it is
App attestation is a protocol where the client device signs a server-issued challenge with a hardware-backed key whose presence is proven to reside only in a genuine app build, so the server can distinguish a real client from a repackaged or scripted one before trusting its requests. Applied in mobile banking, anti-fraud, and any API where the business risk of a modified client (rate limit evasion, abuse) justifies the integration cost. The threat model determines which controls apply: preventive controls block exploits, detective controls surface violations, and corrective controls restore integrity after an incident.
How it works
Effective implementations layer controls so that no single bypass compromises the asset. Verification happens at trust boundaries, not just at the perimeter. Cryptographic primitives are selected for the concrete property needed — unforgeability, indistinguishability, or non-malleability — and never composed ad hoc. Failure modes fail closed: a verification error denies rather than allows.
When to enforce and pitfalls
Enforce wherever an attacker can influence input that crosses a trust boundary. Common pitfalls include treating obfuscation as a control, relying on secrecy of the algorithm rather than the key, and auditing the happy path while ignoring error-handling branches where bypasses often hide. Rate-limit and log every verification attempt so brute-force and oracle attacks become visible.