API Security Testing India — Bachao.AI Methodology

Why API security needs its own methodology

A standard VAPT tests the web app or mobile app. API security needs separate methodology because:

1. APIs are increasingly the entire product surface (mobile apps, SDK customers, B2B integrations all hit the API)
2. OWASP API Top 10 differs from OWASP Web Top 10 (BOLA dominates, not XSS)
3. Rate limiting and authorization at the API layer are where most attacks succeed
4. API documentation is often the most useful artifact for attackers (or the most useful artifact for defenders to validate)

What's in scope

Authentication and authorization (OWASP API Top 10 categories 1, 2, 3, 5):

1. BOLA (Broken Object-Level Authorization) testing on every authenticated endpoint
2. Broken authentication (token reuse, weak JWT signing, session fixation)
3. Excessive data exposure (responses including more than the UI uses)
4. Broken function-level authorization (admin endpoints reachable by non-admin users)

1. Unrestricted resource consumption (rate limits absent or bypassable)
2. Server-Side Request Forgery (SSRF) on URL-accepting endpoints
3. Security misconfiguration (CORS, headers, error messages leaking data)
4. Lack of resources & rate limiting (per-user, per-IP, per-endpoint quotas)
5. Improper inventory management (deprecated API versions still callable)
6. Unsafe consumption of APIs (third-party API responses trusted blindly)

1. UPI API security (intent validation, transaction signing)
2. DigiLocker / Aadhaar API integration security
3. Account Aggregator framework security
4. Payment Aggregator API security per RBI guidelines
5. DPDP-compliant data handling in API responses

The 4-day delivery

Day 1: Documentation and discovery

1. API spec review (OpenAPI / Postman collection / Swagger)
2. Endpoint enumeration (documented + undocumented)
3. Authentication model review
4. Initial automated scanning

1. Every authenticated endpoint tested for object-level authorization
2. Multi-account testing (User A's token attempting to access User B's resource)
3. Vertical privilege escalation (regular user attempting admin endpoint)
4. Horizontal authorization edge cases

1. Rate limiting validation (per-user, per-IP, per-endpoint)
2. SSRF on URL-accepting endpoints
3. Mass assignment testing
4. Input validation edge cases
5. Business logic abuse (race conditions, state machine violations)

1. Findings categorised: Critical / High / Medium / Low
2. Each finding includes PoC + remediation example
3. 90-minute debrief with backend engineering team

Pricing

Common findings

From our last 30 fintech API audits, in order of frequency:

1. BOLA on at least one endpoint (24 of 30 APIs)
2. Rate limit bypass via header manipulation or IP rotation (21 of 30)
3. Excessive data exposure on at least one response (19 of 30)
4. Missing or weak per-user rate limit (17 of 30)
5. SSRF on at least one URL-accepting endpoint (12 of 30)
6. Deprecated API version still callable in production (11 of 30)
7. Verbose error messages exposing stack trace (10 of 30)
8. JWT signing key weak or rotatable (9 of 30)
9. Mass assignment vulnerability (8 of 30)
10. Authorization race condition in transaction endpoints (6 of 30)

How to start

Schedule the API audit scoping call →

Related: Case Study: Fintech API Audit Found BOLA + Rate Limit Bypass · API Security for Indian Fintech