BOLA explained
A payment API endpoint like /api/invoices/88421 returns a payment record when called by user A. The vulnerability exists when user B receives that record simply by knowing the ID. The API authenticated the user but never authorised the specific resource access. BOLA vulnerabilities have scored as high as 9.9 (Critical) on the CVSS scale.
Why predictable IDs turn this into mass exfiltration
Sequential integer IDs transform a single authorisation failure into a mass exfiltration tool. Attackers automate enumeration using bots that cycle through ID ranges in milliseconds. Replacing sequential integers with GUIDs (128-bit random identifiers) cuts mass-guessing success rates to statistically negligible levels. It's not a complete fix on its own, but it removes the arithmetic that makes automated BOLA attacks practical.
Real breach scenarios
T-Mobile: 37 million accounts
In 2023, attackers harvested subscriber data from approximately 37 million accounts through API abuse. The breach combined an unauthenticated endpoint and sequential user IDs. The direct parallel to payment platform user data structures is exact.
Stripe's deprecated endpoint
In 2025, attackers validated stolen cards through a legacy /v1/sources endpoint that lacked modern rate limiting and authorisation controls. Deprecated endpoints without decommissioning policies represent a specific BOLA-adjacent risk.
Coinbase: unauthorised trading
An authenticated user could trigger trades on another user's account by manipulating object identifiers. The platform confirmed the user was logged in, then skipped the ownership check entirely.
Want your payment API tested for BOLA and IDOR vulnerabilities?
Get an API Security AuditThe compounding threat picture
Several OWASP API Top 10 categories interact with BOLA. Broken authentication (API2) accelerates exploitation. BOPLA (API3) allows modification of fields a user shouldn't control. Unrestricted business flows (API6) let automation exploit payment logic. Fix the object-level check, and the blast radius of adjacent vulnerabilities shrinks significantly. For a full OWASP walkthrough, see our OWASP for fintech guide.
What a BOLA breach costs
PCI DSS 4.0 Requirement 6.5.6 explicitly mandates securing APIs against BOLA. The average financial services data breach reached $6.08 million (IBM, 2024). A BOLA-exploited payment API creates immediate compliance exposure across multiple PCI requirements simultaneously.
Mitigation checklist
Authorisation controls
- Every data-access endpoint performs object-level ownership verification
- All object identifiers are non-sequential (GUIDs)
- Sensitive operations require re-authentication or MFA
- Token scopes are minimised to least-privilege per API consumer
- Authorisation policies are defined centrally and audited on each deployment
Monitoring controls
- All API requests to payment resources are logged with user identity, object ID, and timestamp
- Rate limiting is configured per endpoint with alerting on threshold breaches
- Anomaly detection baseline exists for normal transaction patterns
- Deprecated endpoints are inventoried and either decommissioned or isolated
- Third-party API integrations are subject to the same object-level authorisation requirements
Authorisation as architecture, not a backlog item
Teams that treat authorisation as an architectural decision, enforced centrally, tested consistently, and audited on deployment, close most of their exposure. Teams that treat it as a code review comment inherit the risk that T-Mobile, Stripe, and Coinbase encountered.
Related reading
Blog: Fintech API security: 10 steps · Secure your fintech API in Nigeria · 10-point security checklist
Guides: OWASP for fintech · PCI DSS compliance · Security checklist
Services: API security testing · Penetration testing · For payment gateways