Mobile API testing. Where the real damage is.

A mobile app is a client that the attacker fully controls. They can decompile it, read its logic, instrument it at runtime, and modify what it does. So anything the app enforces on the device can be undone. The only thing the attacker cannot directly control is the server.

That makes the API the real security boundary. It is where the app authenticates the user, where authorisation decisions are made, and where business rules are enforced for real. If the API trusts the app to enforce a rule the attacker can bypass, the rule is not enforced at all.

This is why, on most mobile engagements, the high-impact findings are API findings: accessing another user's data, bypassing a purchase limit, escalating privileges. The client-side findings (insecure storage, hardcoded secrets) matter, but the ones that let an attacker reach other users' data or money are almost always in the API.

Before testing the API, the tester has to see its traffic. The steps:

• Intercept the traffic. Route the app's connections through an interception proxy so every request and response is visible.
• Bypass certificate pinning if the app uses it, since pinning blocks the interception proxy. See certificate pinning bypass.
• Map the endpoints. Catalogue every API endpoint the app calls, the parameters each takes, and the authentication each requires.
• Capture authenticated sessions. Get valid tokens for two or more test accounts, so cross-account authorisation can be tested.

Once the traffic is visible and the endpoints are mapped, the API test proceeds the same way a standalone API penetration test would.

The same categories as any API penetration test, applied to the endpoints the mobile app uses:

• Broken Object Level Authorization (BOLA). Can one user access another user's data by changing an ID? The most common and most damaging API flaw. See BOLA.
• Broken authentication. Are tokens issued, validated, and revoked correctly? Can sessions be hijacked or forged? See broken authentication.
• Function-level authorisation. Can a normal user reach admin-only endpoints?
• Client-side trust. Does the API re-check the rules the app enforces locally (prices, limits, permissions), or does it trust the client?
• Input validation and injection. Are the API parameters validated, or are they vulnerable to injection?
• Rate limiting. Can the endpoints be brute-forced or scraped? See rate limit bypass.

The full OWASP API Security Top 10 applies. See the API security topics for the detail on each.

The single most common pattern we see in mobile engagements is the API trusting the app to enforce something the attacker can bypass.

Examples from real engagements:

• The app shows a price and sends it to the API on checkout. The API trusts the price the app sent. An attacker changes it.
• The app hides an admin feature from non-admin users in the UI, but the API endpoint behind it does not check the caller's role. An attacker calls it directly.
• The app enforces a daily transfer limit and sends transactions to the API. The API does not re-check the limit. An attacker removes the client check.
• The app validates input before sending it. The API assumes the input is already validated. An attacker sends raw input.

The root cause is the same every time: a security decision was made on the client, which the attacker controls, and the server trusted it. The fix is the same every time: the server must independently enforce every security-relevant rule, regardless of what the client sends.

Every mobile engagement includes a full API penetration test of the backend the app talks to.

We intercept the app's traffic, bypass pinning where present, and map every endpoint. Then we run the API attack matrix: BOLA across multiple accounts, authentication and session testing, function-level authorisation, client-side-trust testing (replaying modified requests the app would never send), input validation, and rate limiting.

The findings are mapped to the OWASP API Security Top 10 and the relevant OWASP MASVS categories, each with a reproducible request and the specific server-side change required. Because the API is the real boundary, this is usually where the report's most serious findings are.