Introduction

Restricting an API to requests from only your mobile app is a common goal, but there is an important reality: no client-side signal is fully trustworthy by itself. A determined attacker can reverse engineer mobile binaries, proxy traffic, and replay captured requests. The practical solution is layered server-side controls that make abuse expensive and detectable.

Build a Realistic Security Model

The first step is to define what you are defending against. If the threat is casual script abuse, basic auth and rate limits may be enough. If the threat includes reverse engineering and token replay, you need stronger controls such as app attestation, nonce-based request signing, and short-lived credentials.

A useful way to think about this:

• identity: who is calling,
• integrity: was this request tampered with,
• freshness: is this request new or replayed,
• device confidence: does this client look like a legitimate app instance.

The API should make authorization decisions primarily on server-verified claims, not on easily spoofed values such as User-Agent or custom headers.

Require Strong User and Session Authentication

Do not rely on app secrets embedded in mobile code. Instead, use user-centric auth with short-lived access tokens and rotating refresh tokens.

Typical baseline:

• OAuth 2.0 or OpenID Connect login,
• access token lifetime measured in minutes,
• refresh token rotation with revocation,
• server-side session risk checks.

Minimal Express middleware example for token verification:

1import jwt from "jsonwebtoken";
2
3export function authMiddleware(req, res, next) {
4  const header = req.headers.authorization || "";
5  const token = header.startsWith("Bearer ") ? header.slice(7) : null;
6
7  if (!token) {
8    return res.status(401).json({ error: "missing_token" });
9  }
10
11  try {
12    const payload = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
13      algorithms: ["RS256"],
14      issuer: "https://auth.example.com",
15      audience: "mobile-api",
16    });
17    req.user = payload;
18    next();
19  } catch {
20    return res.status(401).json({ error: "invalid_token" });
21  }
22}

This proves user identity, but it does not yet prove that the call came from your official app binary.

Add App and Device Attestation

Use platform attestation mechanisms:

• Android Play Integrity API,
• iOS App Attest and DeviceCheck.

Your backend should verify attestation artifacts server-side and map outcomes to risk levels. A common policy is to allow low-risk operations for weaker signals, but require strong attestation for sensitive endpoints such as payments, password changes, and account recovery.

Treat attestation as a confidence input, not an absolute truth. Devices can fail checks for legitimate reasons, so design graceful fallback paths such as step-up authentication.

Protect Against Replay with Signed Request Metadata

Even valid tokens can be replayed if intercepted. Add request-level freshness checks using timestamp plus nonce.

Server-side pattern:

1. mobile client sends X-Nonce and X-Timestamp,
2. server verifies timestamp skew window,
3. server rejects reused nonce for same principal.

Minimal Python example for nonce replay guard:

1from datetime import datetime, timezone
2
3# replace with Redis or another shared store in production
4seen = set()
5
6
7def verify_fresh_request(user_id: str, nonce: str, ts_unix: int) -> bool:
8    now = int(datetime.now(timezone.utc).timestamp())
9    if abs(now - ts_unix) > 120:
10        return False
11
12    key = f"{user_id}:{nonce}"
13    if key in seen:
14        return False
15
16    seen.add(key)
17    return True

In production, nonce storage must be centralized and expiring, typically Redis with TTL.

Apply Abuse Controls and Observability

Even with strong auth, enforce behavioral controls:

• rate limits by account, device, and IP,
• endpoint-specific throttling,
• anomaly detection for impossible travel and burst patterns,
• audit logging for denied requests with reason codes.

Good telemetry is critical. If controls trigger without clear logs, operations teams either disable protections or spend too long diagnosing false positives.

Rollout Strategy That Avoids Breaking Legitimate Users

Deploy in phases:

1. observe-only mode with no hard blocking,
2. soft enforcement on high-risk actions,
3. full enforcement once false-positive rate is acceptable.

Keep feature flags around attestation and replay checks so emergency rollback is safe and fast.

Common Pitfalls

• Treating an embedded API key as sufficient app identity proof.
• Relying on spoofable headers as the main restriction mechanism.
• Using long-lived access tokens with no revocation strategy.
• Enforcing attestation without fallback and locking out legitimate users.
• Blocking requests without actionable telemetry for operators.

Summary

• You cannot perfectly prove request origin from mobile client data alone.
• Strong restriction comes from layered server-side verification.
• Combine short-lived auth tokens, app attestation, and anti-replay checks.
• Add rate limits and anomaly detection to contain automated abuse.
• Roll out gradually with observability and reversible controls.