mobile-backend

Start by discovering endpoints through directory fuzzing with spray or ffuf, checking /swagger and /openapi.json, and intercepting traffic with Burp or Charles. Then test authentication mechanisms, probe for IDOR by changing object IDs, and tamper with business logic parameters like price and quantity.

Combine three approaches: fuzz common paths like /api/v1/ and /mobile/api/ with wordlists, review exposed documentation at /docs or /redoc, and decompile the APK to search for hardcoded URL strings. Traffic capture with Burp or Charles reveals endpoints the app actually calls.

An API version downgrade attack targets older endpoint versions such as /api/v1/ when the current /api/v3/ enforces proper authorization. Projects often keep legacy versions online without backporting security fixes, so requesting the same resource through v1 or v2 may bypass authentication checks.

Common techniques include brute-forcing 4-6 digit codes when no rate limit exists, tampering with the verification response to change failure into success, trying default codes like 000000 or 123456, and checking whether the API response itself leaks the generated code.

Yes, it identifies JWT Bearer tokens, API Keys, OAuth token endpoints, and custom signature headers, then directs you to dedicated JWT and OAuth attack methodologies. It also covers generic bypass tests such as missing tokens, expired tokens, and modified user_id or role claims.

Mobile backends typically trust the client more because requests bypass the browser, so developers implement fewer server-side validations. This leaves price fields, quantity values, and device identifiers client-controlled, making tampering and authorization flaws more common than in traditional web applications.