Case Study: Chaining BOLA and IDOR in a Fintech API Pentest

Compiled from an engagement completed under bilateral NDA. Client, endpoints, and data details are anonymized. The goal is a concrete reference for teams running similar architectures.

Client Profile and Scope

Sector: Licensed payment institution (within KVKK/GDPR and PCI DSS scope)

System: Multi-tenant payment API — tenant-isolated transaction history, webhook notifications, and admin panel

Engagement: 2-week black-box API penetration test + gray-box validation with authorized accounts

Rule: Scanner output is not reported; every finding ships with exploitation evidence (PoC).

Reconnaissance: Mapping the Attack Surface

The first three days were standard recon: OpenAPI schema reverse engineering, JWT structure analysis, and a role-based endpoint matrix. Two signals stood out:

The tenant ID traveled in the request body, not the JWT — meaning server-side authorization depended on client-supplied data.
The transaction listing endpoint accepted a monotonically increasing internal record ID in pagination parameters.

Critical Finding: The BOLA Chain (CVSS 9.1)

On GET /v1/transactions/{id}, an authenticated session belonging to tenant A requested a transaction ID owned by tenant B. The server returned HTTP 200 with full transaction detail. Ownership was never verified — only session validity.

The second link in the chain: transaction IDs were sequential. This turned the IDOR from a single-record leak into bulk data extraction — a scripted attacker could enumerate millions of records.

Proven impact: Amounts, counterparty names, masked IBANs, and internal description fields. A personal data breach under GDPR/KVKK, and adjacent to cardholder data under PCI DSS.

Secondary Finding: Webhook Signature Bypass (CVSS 7.5)

Webhook validation read the HMAC from the X-Signature header — and skipped verification when the header was absent. Removing the header entirely caused a forged "payment succeeded" notification to be accepted: an order could be fulfilled without payment, a pure business-logic failure.

Remediation and Retest

The report shipped with code-level remediation guidance per finding:

Finding	Fix	Retest
BOLA	Object-ownership check moved to middleware; tenant context enforced from JWT claims	48h later, all cross-tenant requests return 403 ✓
Sequential IDs	Migration to UUID v7 + rate limiting	Predictability eliminated ✓
Webhook	Mandatory signature, reject on missing header, timestamp tolerance	Forged notifications rejected ✓

Total timeline: 19 days from discovery to retest sign-off.

Checklist for Similar Architectures

Is object ownership verified server-side on every access?
Does tenant context come from a verified token, not client data?
Are sequential IDs exposed externally?
Does webhook verification "skip if absent"?
Are authorization tests converted into automated regression tests?

This checklist alone is not enough — chained attack paths can only be validated by attempting real exploitation.

Engagement Timeline: How 19 Days Were Spent

Day	Phase	Output
1-3	Reconnaissance	OpenAPI reverse engineering, endpoint matrix, JWT analysis
4-6	Authentication testing	JWT validation chain, OAuth flows, role transitions
7-9	BOLA/IDOR hunting	Cross-tenant test matrix, first proof-of-concept
10-11	Webhooks and business logic	Signature bypass, forged notification scenario
12-13	Evidence standardization	Reproducible PoC per finding, CVSS scoring
14-16	Report writing	Executive summary + code-level remediation guide
17	Delivery + findings walkthrough	Live session with the engineering team
18-19	Retest	Verification of fixes, closure sign-off

The first evidence for the critical BOLA finding was produced on day 9; the client started fixing on day 10 without waiting for the report. That is part of our engagement rules: critical findings are escalated over a secure channel immediately, without waiting for report writing.

Would the Client Have Caught This Chain Themselves?

The most common post-engagement question: "Would our detection systems have caught this?" The honest answer in this case: no. Here's why, and what to do about it:

1. Authorization failures are invisible in logs. A cross-tenant request is, from the server's perspective, "a normal request with a valid session" — it returns HTTP 200 and raises no alert. Fix: dedicated metrics on ownership-check rejections (403s) in the authorization middleware; anomaly alerts when a single session touches multiple tenant IDs.

2. WAFs don't see this class of vulnerability. BOLA/IDOR is the blind spot of signature-based detection: the request is perfectly well-formed, only the ID differs. Fix: application-layer authorization unit tests + an authorization regression suite in CI/CD.

3. The webhook bypass is silent. When an unsigned notification is accepted, the log shows "webhook processed successfully." Fix: signature-validation rejection counter; immediate alert on unsigned notification attempts.

All three detection rules were delivered to the client with the remediation and added to their SIEM. That is penetration testing's second value: closing the vulnerability + being able to monitor that it stays closed.

Business Value of the Findings: Not Just Technical Risk

Finding	Technical impact	Business impact
BOLA chain	Cross-tenant data access	GDPR/KVKK breach notification, customer trust, PCI DSS compliance risk
Sequential IDs	Bulk data extraction	Mass leak = mass notification obligation
Webhook bypass	Order fulfillment without payment	Direct revenue loss, reconciliation failures

Showing this table in the executive briefing is what earns the technical finding budget and priority. A security finding narrated in business language doesn't rot at the bottom of the backlog.

Methodology Notes: A Systematic Approach to BOLA Testing

The steps followed in this engagement form a template for similar tests:

Identity matrix: obtain a token per role (tenant admin, tenant user, read-only), build an expected-authorization table per endpoint
Cross-access automation: automatically try role-A tokens against role-B resource IDs; every 200 response is suspect
ID semantics: sequential, UUID, or encrypted? If sequential, probe the predictable range
Response comparison: endpoints with ownership checks return 403/404; 200 + partial data is also a leak form (compare field by field)
Chain evaluation: a finding's severity changes when combined into a chain — score CVSS at the end of the chain, not the single link

Frequently Asked Questions

What's the difference between BOLA and IDOR?

IDOR (Insecure Direct Object Reference) is the technical name of the flaw: using a direct object reference without verifying authorization. BOLA (Broken Object Level Authorization) is the category name from the API Security Top 10 — the same problem described in the API context. In practice, two names for the same issue from two perspectives.

Is it correct to start fixing before the report is delivered?

For critical findings, yes — an live attack path is daily risk. Our engagement rule: critical findings are escalated immediately over a secure channel; the client starts fixing; the report arrives with full context on all findings. Remediation and reporting run in parallel, not in sequence.

How do you scope authorization testing in multi-tenant architectures?

Not tenant-count × combinations, but a role × resource-type matrix: for each role, access attempts against own-tenant and foreign-tenant resources. The matrix can be auto-derived from the OpenAPI schema; manual effort focuses on suspicious combinations.

Request a Pilot

To plan a similar validation for your payment or financial infrastructure, request a scoping call. We return a scope proposal within 48 hours.