Case Study: Fintech API Security Audit Found BOLA + Rate Limit Bypass

The situation

A Mumbai-based digital lending fintech (we'll call them "LendCo") was preparing for SOC 2 Type II observation. Their lending platform API was the core product surface — used by their own mobile app + 4 partner integrations + a B2B SDK. LendCo's CISO commissioned a Bachao.AI API security audit before the SOC 2 observation period began.

LendCo's profile:

1. 60 employees, 4 lakh borrowers
2. API-first architecture (~180 documented endpoints)
3. Node.js + Postgres backend
4. AWS-hosted, behind CloudFront + WAF
5. RBI-regulated, payment aggregator licence pending

The audit (Week 1)

The Bachao.AI 4-day API audit returned:

C-001 — BOLA on loan detail endpoint

The GET /api/v2/loans/{loan_id} endpoint validated user authentication but not authorization. Any authenticated user could read any other user's loan record by enumerating loan IDs.

PoC: User A authenticated with their own token, then enumerated 100 random loan IDs. 87 returned data including borrower name, PAN, loan amount, EMI schedule, KYC documents.

Business impact: full customer data exposure. DPDP Section 8 (data principal access) compromise. Potential RBI regulatory finding.

Remediation: add authorization check (loan.borrower_id === request.user.id OR request.user.role === 'admin') on every loan-data endpoint. Estimated 6 endpoints needed similar fix.

C-002 — Rate limit bypass via X-Forwarded-For header

The rate limit middleware used X-Forwarded-For as the source IP without validation. Attacker could send arbitrary IP in the header, bypassing per-IP rate limits.

PoC: 10,000 requests to the loan-detail endpoint in 60 seconds, each with a different X-Forwarded-For value. All accepted by the API.

Business impact: combined with C-001, allowed full enumeration of the customer database in under 1 hour.

Remediation: validate X-Forwarded-For against trusted CloudFront IPs; use the real source IP from CloudFront's X-Forwarded-For chain end.

H-001 — Mass assignment on user profile update

PUT /api/v2/user/profile accepted any JSON body and updated matching DB columns. Allowed user to update kyc_status, credit_score, and other server-controlled fields.

H-002 — JWT signing key in environment variable, no rotation procedure

If the environment variable leaked (compromised CI/CD, misconfigured logging), all issued JWTs could be forged.

H-003 through H-007 — verbose error messages, weak per-user rate limit on auth endpoints, SSRF on a webhook configuration endpoint, deprecated v1 API still callable, missing CORS validation on admin endpoints.

The remediation sprint (Week 2)

Bachao.AI worked with LendCo's backend lead:

Day 8: C-001 (BOLA on loan endpoint) — refactored the loan-data layer to enforce authorization in a single middleware. 6 endpoints fixed in one PR. Reviewed jointly.

Day 9: C-002 (rate limit bypass) — refactored the rate limit middleware to use CloudFront's authoritative source IP. Tested against 10,000-request bypass attempt; bypass no longer possible.

Day 10: H-001 (mass assignment) — explicit allowlist of updatable fields. Estimated 4 endpoints had the same pattern; all fixed.

Day 11: H-002 (JWT key rotation) — implemented JWK rotation with grace period. Documented rotation procedure.

Day 12-14: H-003 through H-007 closed; Medium and Low findings prioritised.

End of Week 2: all Critical + High findings closed. 8 of 11 Medium findings closed.

The re-test (Week 3)

Bachao.AI re-tested every Critical and High finding:

1. C-001: 100 random loan IDs tested with User A's token. All returned 403. Authorization verified working.
2. C-002: 10,000-request bypass attempt. Rate limit kicked in at request 100. Verified.
3. H-001 through H-007: each verified closed.

What it cost

What LendCo's CISO said

"The BOLA finding was the kind of thing you read about in breach reports. Bachao found it in 4 days. The remediation was the right kind — we fixed the underlying authorization layer, not just the endpoint that was found. The whole codebase is safer now. Our SOC 2 auditor accepted the evidence on first review."

Pattern this engagement followed

This is a common shape for Bachao.AI API security engagements:

1. API-first product where the API is the product
2. Multiple consumers (mobile, partner integrations, B2B SDK)
3. Authentication is solved but authorization has rough edges
4. Compliance event (SOC 2, RBI, customer questionnaire) driving the audit

Schedule the API audit scoping call →

Related: API Security Testing Methodology · API Security for Indian Fintech