# Mobile API security review checklist
Author: Jeffrey Monica · ZombieMutex · https://zombiemutex.com/guides
Purpose: a repeatable, authorized engineering review of iOS/Android clients and backend APIs.

This is a **review worksheet**, not a certification or an automated penetration-test result.
Run tests only on systems you own or are explicitly authorized to assess.

## 1. Record the trust boundaries

- [ ] Write down the principal, tenant, API route, action, resource ID, and fields that change state.
- [ ] Distinguish app/device integrity, authentication, per-object authorization, and fraud/risk scoring.
- [ ] Identify all data controlled by the mobile client and every operation requiring independent server-side enforcement.
- [ ] Capture request IDs and expected outcomes without recording credentials or personal data.

## 2. iOS App Attest review

- [ ] Backend issues a unique, unpredictable, one-time challenge.
- [ ] App registers an attested key; backend verifies the attestation and expected app/environment identity.
- [ ] Backend stores the verified public key and expected assertion state per device/key.
- [ ] Subsequent assertions are validated against expected action data, challenge, signature and monotonic counter.
- [ ] Replay, old counter, mismatched app identity, invalid challenge and unexpected device/key are rejected.
- [ ] Unsupported-device, reinstallation, environment mismatch, timeout and key-recovery paths have an explicit policy.
- [ ] Valid attestation never bypasses user authentication or resource authorization.

Official: https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server

## 3. Android Play Integrity review

- [ ] Protect specific sensitive operations, not just app launch.
- [ ] Standard request includes a canonical hash of security-relevant request values in requestHash.
- [ ] Backend obtains the decoded verdict from Google Play and checks application and device signals according to policy.
- [ ] Backend recomputes the hash for the received action and compares it to the decoded requestHash.
- [ ] Handle replay, mismatched hash, absent or unexpected verdict and service errors deliberately.
- [ ] Valid integrity evidence never grants implicit ownership of an object or user-session identity.

Official: https://developer.android.com/google/play/integrity/standard

## 4. Authorization and request-shape tests

- [ ] Create two controlled tenants and resources, plus low- and high-privilege test accounts.
- [ ] Attempt each tenant's GET/PATCH/PUT/DELETE using the other tenant's resource ID.
- [ ] Test nested resource IDs and both direct and indirect reference paths.
- [ ] Inject server-owned fields (role, ownerId, privileges, status) into ordinary update payloads.
- [ ] Confirm allowlisted fields and object-level checks apply to each action, including cached/idempotent responses.
- [ ] Document each expected rejection and verify no unintended durable state changes.

Official: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

## 5. Replay, token rotation and retry tests

- [ ] Send identical one-time challenges or nonces sequentially and concurrently; duplicate use is rejected atomically.
- [ ] Replay a superseded refresh token and test simultaneous refreshes; enforce the documented rotation/family policy.
- [ ] Simulate a committed write whose HTTP response is dropped, then retry with the same idempotency key.
- [ ] Check that only one durable write occurs and a safe repeat returns the original outcome.
- [ ] Ensure a reused key with a materially different request is rejected rather than replaying an unrelated result.
- [ ] Scope idempotency keys to the authenticated caller/operation and define retention/retry windows.

## 6. Evidence and regression

- [ ] Capture initial test state, exact changed request field, concurrency ordering, response and final persistent state.
- [ ] Add a negative regression test before changing the enforcement rule.
- [ ] Verify correct failures are distinguishable from networking or infrastructure errors.
- [ ] Avoid secrets and sensitive payloads in error logs, metrics and test artifacts.
- [ ] Identify whether evidence comes from a synthetic model, a local application, or an authorized real assessment.

## Browser-only synthetic examples

- https://zombiemutex.com/labs/device-attestation
- https://zombiemutex.com/labs/break-fix
- https://zombiemutex.com/labs/api-retries
- https://zombiemutex.com/guides/app-attest-vs-play-integrity
- https://zombiemutex.com/guides/api-replay-authorization-testing

Share or adapt this worksheet with attribution to its original URL; no backlink is required.