DeviceCheck and App Attest: Stopping Fraud in iOS Apps
Discover how DeviceCheck and App Attest frameworks from Apple stop bot traffic, simulator farms, and promo abuse in iOS applications.
Stock photo for illustration only, not from the actual event
- HTTPS encrypts connections but proves nothing about the client app
- DeviceCheck (iOS 11+) provides two bits of storage surviving app reinstalls
- App Attest (iOS 14+) uses Secure Enclave hardware for cryptographic request proofs
- Servers must handle validation independently to prevent client-side bypass
A request arriving at POST /api/redeem looks identical whether it originated from your application running on a genuine iPhone, from a modified build executing on a jailbroken device, or via a Python script scripted after inspecting traffic in Charles Proxy. The HTTPS protocol ensures that the connection remains encrypted, yet it provides zero proof regarding the actual identity of the client sending the payload.
Apple offers two distinct frameworks designed to bridge this security gap. This article explores the specific guarantees each framework provides, their inherent limitations, and how developers can implement both without falling into common pitfalls often found in standard tutorials.
The first tool is DeviceCheck, available on iOS 11 and newer versions, which fulfills two specific functions: confirming that a token originates from a genuine Apple device with your app installed under your developer account, and providing two bits of storage per device per developer hosted on Apple servers. Those two bits yield four possible states and persist even when the user deletes and reinstalls the application.
It is important to note what DeviceCheck does not do: it does not detect jailbroken environments, does not verify binary modifications, does not identify individual users, and does not function as an authentication system. However, the persistent two-bit storage successfully addresses tracking questions that local storage flags cannot resolve across reinstalls.
Stock photo for illustration only, not from the actual event
When handling tokens generated by the generateToken function in DeviceCheck, developers must treat each token as single-use. Although a token remains valid long enough to retry a specific network request, reusing the same token multiple times introduces security vulnerabilities. Generating a fresh token for every distinct request ensures robust protection against replay attacks.
The second framework, App Attest, introduced in iOS 14 and later, addresses a much more rigorous question: is this specific request originating from an unmodified copy of your application? It operates by generating a cryptographic key pair within the physical device's Secure Enclave hardware, ensuring the private key never leaves the hardware boundary.
"App Attest turns 'rate limit the abuse' into 'the abuse's cannot reach the endpoint.'"
Dev.to
The workflow is split into attestation—which occurs once per key installation involving Apple servers and is relatively resource-heavy—and assertion, which happens on every subsequent request and remains lightweight without Apple server involvement. Your own backend infrastructure must parse the CBOR attestation object and validate the certificate chain against Apple roots rather than trusting the client.
Deploying both frameworks in production effectively neutralizes bot automation, credential stuffing attempts, free-tier farming through emulators, promo abuse, and unauthorized sideloaded IPA modifications.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment