API Security Testing: From Recon to Exploit in Seven Phases
Cybersecurity
Modern APIs expose more attack surface than any web UI ever did. A structured methodology for taking an API from unknown endpoints to confirmed critical findings — covering auth flaws, mass assignment, BOLA, and injection chains.
By Arjun Raghavan, Security & Systems Lead, BIPI · June 2, 2025 · 11 min read
REST, GraphQL, gRPC, and WebSocket APIs now carry the bulk of application logic that used to live in server-rendered HTML. The OWASP API Security Top 10 2023 update catalogued the same class of bugs that have dominated HackerOne payouts for three consecutive years. The methodology has to match the surface.
Phase 1 — Endpoint Discovery
Start before you touch Burp. Pull the OpenAPI or Swagger spec from /api-docs, /swagger.json, /openapi.yaml. Run kiterunner against the base URL with the assetnote wordlist. Diff the spec against what kiterunner finds — the delta is undocumented endpoints that usually have weaker auth because developers assumed nobody would find them.
Phase 2 — Authentication and Token Analysis
Collect every token format in use. JWTs should be inspected for alg:none, weak secrets (hashcat with rockyou on HS256 signatures), and jwk header injection. API keys should be tested for scope isolation — does key A belonging to tenant A reach tenant B objects? Rotate the key mid-session and observe whether in-flight requests are immediately rejected or continue for a grace window.
Phase 3 — BOLA and IDOR Mapping
- Collect every object identifier in responses: numeric IDs, UUIDs, slugs, encoded strings.
- Create two accounts in separate tenants. Substitute identifiers cross-tenant on every write and read endpoint.
- Watch for 200 with wrong tenant data, 403 that leaks object existence, or 404 that differs between object-exists and object-forbidden.
- Test indirect references: /invoice/download?file=2024-q1.pdf — traverse to ../../../etc/passwd.
Phase 4 — Mass Assignment and Overposting
Grab a GET /users/{id} response. Add every field from the response body back into a PATCH request. Common wins: role, isAdmin, emailVerified, credits, subscription_tier. Frameworks that auto-bind request fields to model attributes are vulnerable by default unless an allowlist is declared explicitly.
The most dangerous API bugs are not injections. They are logical flaws that only appear when you compare what two different users can see about the same object.
Phase 5 — Rate Limiting and Business Logic
Test every state-changing endpoint without a rate limit header. Password reset OTP endpoints, coupon redemption, referral credit systems, and file export endpoints are historically undertested. Send 50 concurrent requests using Turbo Intruder single-packet attack. OTPs with six digits and no rate limit are brute-forced in under two minutes.
Phase 6 — Injection in API Parameters
Filter and sort parameters are the new SQL injection vectors. ?filter=name:eq:alice is often passed directly to an ORM query builder. Try ?filter=1=1, ?filter=name:ne:'' and observe response size changes. GraphQL introspection followed by union-style nested queries can exhaust server memory if depth limiting is absent.
Phase 7 — Reporting and Remediation Guidance
Every finding needs a reproduction curl command, the exact response diff, and a one-line remediation. BOLA: enforce ownership check in service layer, not just routing layer. Mass assignment: declare field allowlists in serialiser. Rate limiting: token bucket at the API gateway per IP and per user with burst tolerance of three.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.