Module 4 · Mobile Backend API Testing 🔒

The mobile app is a client. Behind it is an API — and the API is where most impactful mobile-pentest findings live. This module covers testing that API surface specifically from a mobile context: endpoints the web app does not call, weaker auth assumptions, and the parameter fields that mobile-only flows tend to trust.

Why mobile APIs are often weaker

• Developers assume the mobile client is harder to inspect and reason about — so they trust it more
• Mobile backends often expose more endpoints than the web backend — device registration, push tokens, in-app-purchase receipts
• Mobile sessions often last longer (weeks to months) with refresh tokens; compromise is higher value
• Rate limiting is often looser on mobile endpoints to accommodate poor network conditions
• Mobile APIs often carry device identifiers that are treated as authentication factors — rarely correctly

Mapping the API surface

From the Burp traffic you captured during Modules 2/3:

1. Extract every unique hostname + path combo
2. Group by endpoint family (auth, user, payments, content, telemetry)
3. Diff against the web app’s API surface if both exist — endpoints unique to mobile deserve extra scrutiny
4. Note authentication modes per endpoint (bearer token? device ID? signed request? session cookie?)

Burp’s Site map view does most of this for you. Export to a CSV for systematic coverage tracking.

Device registration and the trust-the-client problem

A typical mobile app on first launch registers with the backend — sends device ID, model, OS version, push token. The server often returns a device-scoped token used for subsequent API calls. Test cases:

• Can you register a device without valid user credentials, receive a token, and use it?
• Can you re-register someone else’s device ID and hijack their push notifications?
• Does device ID spoofing change what the API returns? (Some apps give “trusted device” privileges based on device ID alone)
• Can you bypass onboarding checks by registering a device with an older API version header?

Authentication patterns to probe

Bearer tokens in Authorization header

Standard. Test expiration, reuse after logout, token scope enforcement, and signature verification if JWT.