Common Pentest Methodology

## PTES-aligned API and mobile penetration-test plan

### 1. Scope and authorization

Obtain written authorization before testing and run all dynamic probes only against an agreed local or staging environment, never production. Record the test window, source IPs/devices, test accounts, data-handling rules, rate limits, and emergency stop contact. Use a grey-box approach where API documentation, mobile builds, test credentials, and architecture/dependency inventories are available. In scope are the API, authentication and authorization flows, API integrations used by the mobile app, and iOS/Android client behavior. Explicitly list excluded hosts, third-party services, destructive actions, and real user data.

### 2. Reconnaissance and inventory

Build a versioned inventory from OpenAPI specifications, gateway routes, app traffic, deep links, exported components, and configuration. For every endpoint record method, path, parameters, object identifiers, required roles, tenant boundaries, state-changing behavior, and whether it is reachable from each mobile platform. Inventory login, refresh, logout, password reset, MFA, file upload, search/filter, bulk, admin, payment, and background-sync APIs. Decompile or inspect the test builds for hardcoded endpoints, feature flags, WebViews, storage locations, certificate-validation behavior, exported Android components, iOS URL schemes, and API versions.

### 3. Threat model and test accounts

Prioritize object reads and writes, tenant-scoped resources, nested resources, bulk endpoints, exports, and administrative actions. Create controlled accounts representing anonymous, user A, user B, another tenant, support/admin, and revoked/expired sessions. Seed uniquely identifiable records owned by each account. Define expected authorization for every object and action before testing so a successful response is not mistaken for legitimate access.

### 4. BOLA/authorization testing

For each object reference, replay the same request while changing only the identifier to a record owned by another user or tenant. Test GET, POST, PUT/PATCH, DELETE, download, share, restore, and bulk variants; test numeric, UUID, slug, nested, alternate API-version, and duplicate-parameter forms. Repeat with changed HTTP methods, content types, pagination/export parameters, and mobile-generated requests. Check both horizontal access (peer user/tenant) and vertical access (ordinary user versus privileged operation), including mass assignment of ownership, role, tenant, status, and approval fields.

Every confirmed finding must have a minimal reproducible PoC: sanitized request, actor identity, target object ownership, response/status and observable unauthorized effect, plus a control request that correctly fails. Capture evidence without exposing sensitive data. Assess blast radius, cross-tenant impact, read versus write capability, and whether cached/mobile-offline data increases exposure. A hypothesis without this exploit evidence is not reported.

### 5. SQL injection testing

Identify database-backed inputs in query, filter, sort, search, report, export, login, JSON, GraphQL, and path parameters. Start with harmless syntax/error probes in staging, then use time-based or boolean-based confirmation with bounded delays and unique markers. Test URL-encoded, JSON-encoded, multipart, duplicate, array, and Unicode representations, while respecting rate limits. Compare a baseline request against one changed input and a safe negative control; distinguish database behavior from validation, caching, or network noise. Validate whether the issue is authenticated-only, tenant-restricted, read/write capable, and reachable through the mobile API. Do not extract unnecessary records; prove impact with the minimum controlled value or a non-destructive marker. Report only when a repeatable PoC demonstrates database interpretation and impact.

### 6. Mobile-specific coverage

On supported iOS and Android test devices, intercept authorized API traffic, verify TLS and certificate handling, inspect Keychain/Keystore and logs for tokens, test logout/revocation and offline synchronization, and examine WebViews, deep links, intents, exported components, and local permission checks. Confirm that server-side BOLA controls remain effective when requests are replayed outside the app and that SQLi-relevant validation is not only client-side. Test both clean and rooted/jailbroken test fixtures where authorized, without treating client tampering alone as an API vulnerability.

### 7. Reporting and retest

Correlate manual tests with relevant SAST/DAST/SCA results; raw scanner output is not a finding. For each confirmed issue provide title, affected endpoint/platform, prerequisites, severity and CVSS rationale, exact PoC, evidence, impact/blast radius, remediation, and regression test. Map findings to applicable OWASP API and mobile controls and organizational compliance requirements. After remediation, replay the original PoC and negative controls on the same builds and API version, then run regression tests for adjacent object types and parameter forms. Close only when the exploit is no longer reproducible and the authorization boundary is enforced server-side.