Real-World Lessons of Broken Object Level Authorization (BOLA)

Coinbase, a world-leading cryptocurrency trading platform, has become a household name in the fintech space. As one of the largest and most trusted exchanges for buying, selling, and storing digital currencies, Coinbase's infrastructure handles millions of users and billions of dollars in transactions daily. Given the sensitive nature of this data, API security is critical to the integrity of Coinbase's platform and to safeguarding the assets of its users.

In 2021, a severe vulnerability in Coinbase's API exposed the risks that can arise when proper authorization logic is absent. This breach serves as a textbook case for Broken Object Level Authorization (BOLA), one of the most critical flaws in API security that continues to be highlighted in the OWASP API Security Top 10. This incident not only showed the devastating effects of a missing authorization check but also provided valuable lessons in securing fintech APIs.

What Happened: The Coinbase API Vulnerability

The hacker (a researcher) observed API traffic when making a trade and deciphered the format of the request, which referenced their source and target accounts, the asset being sold/bought, the limit price and quantity. The researcher legitimately owned Ethereum on the European market. They submitted an API request to sell their holding, but modified the asset name to Bitcoin - something they did NOT OWN. They submitted the request expecting to get an error response, but instead received a trade confirmation. They sold their $1000 of Ethereum as $43,000 of Bitcoin! This is a great example of a logic vulnerability and could only have been exploited at the API level, not at the UI level.

How the Exploit Worked: Technical Breakdown

To understand how the researcher exploited the vulnerability, we need to look at how the API's backend and web interface communicate. The researcher reverse-engineered the traffic between the Coinbase web interface and its backend servers, identifying vulnerable API calls that did not properly validate ownership of assets during transactions.

There were four crucial API parameters involved in this exploit:

1. Product ID – Identifies the cryptocurrency product being traded (e.g., Bitcoin, Ethereum).
2. Order Type – Defines the type of transaction (e.g., sell, buy).
3. Source Account – The account from which the cryptocurrency would be sold.
4. Target Account – The account that would receive the cryptocurrency.

The critical flaw in the API was the lack of proper authorization checks on the asset type parameter, not the account itself. The researcher legitimately owned the account but was able to manipulate the API request to change the asset type from Ethereum (which they did own) to Bitcoin (which they did not).

Because the API never validated whether the user actually held that specific asset, the system accepted the request and allowed trades involving a currency they didn’t possess.

This is a textbook example of Broken Object Level Authorization (BOLA) the API failed to confirm ownership or authorization at the object level (in this case, the traded asset), allowing unintended access within a legitimate user’s own account.

Broken Object Level Authorization (BOLA) in Action

This breach is a prime example of OWASP API Security Principle #1 Broken Object Level Authorization.

BOLA occurs when an API does not properly check whether a user is authorized to access or manipulate a specific object (such as a user account, order, or product). APIs, unlike user interfaces, provide opportunities for attackers to manipulate requests directly by modifying object identifiers. In this case, the attacker was able to change the source account in the request to sell crypto from another user’s account without proper authorization checks.

To better understand BOLA, check out our API Blog on BOLA, which covers common API vulnerabilities.

Coinbase’s Response: From Breach to Resolution

Once Coinbase became aware of the vulnerability, they acted swiftly to shut down the affected services. The company worked quickly to reproduce the issue, fix the bug, and secure the system. Within a day, the issue was resolved.

Coinbase fixed the issue by tightening how the API validated the Product ID tied to each trade.
Previously, users could change the asset type in an API call for instance, switching from Ethereum (which they owned) to Bitcoin (which they didn’t). The system didn’t double-check whether that Product ID actually matched the assets in their account.

After the fix, Coinbase added logic that verified every transaction’s Product ID before processing it. If the asset didn’t belong to the user, the API returned a clear error message:
“Source account does not match Product ID.”

That small change confirming that each trade request matched a valid asset the user truly owned effectively closed the loophole and stopped unauthorized asset swaps.

Coinbase's transparency in blogging about the breach, detailing their immediate actions, and offering a detailed explanation in the Coinbase Security Blog served as a key lesson in accountability.

Lessons for API Developers: Preventing BOLA Vulnerabilities

The Coinbase breach underscores the importance of strong authorization checks at the API level. Here are some actionable steps for API developers to prevent BOLA vulnerabilities:

1. Validate Ownership at the API Layer: Always ensure that users can only access or manipulate their own data. Implement server-side validation to check if the authenticated user has the right to interact with the specific object requested.
   
   
2. Use Strong Object Identifiers: Avoid using easily guessable or sequential identifiers (like user IDs). Instead, use unique and non-predictable identifiers (e.g., UUIDs) to prevent attackers from guessing or manipulating object IDs.
   
   
3. Regularly Test for Logic Flaws: Regular penetration testing, manual reviews, and automated security tools are essential for detecting logic flaws that can lead to BOLA vulnerabilities.
   
   
4. Automate API Security Testing with Tools: APIsec.ai provides automated API security testing, continuously detecting BOLA and other vulnerabilities as part of your CI/CD pipeline. By integrating APIsec.ai into your workflow, you can proactively identify vulnerabilities before they’re exploited.

Conclusion

The Coinbase API security breach is a textbook case of Broken Object Level Authorization (BOLA), highlighting the devastating consequences of missing authorization checks in APIs. This real-world lesson demonstrates the importance of proper authorization at every level of the API lifecycle.

By implementing strong authorization logic, regularly testing for vulnerabilities, and using tools like APIsec.ai, developers can avoid BOLA and ensure their APIs are secure. API security is an ongoing process, and learning from these high-profile breaches is critical to protecting your systems from future attacks.

FAQs

1. What is Broken Object Level Authorization (BOLA)?

BOLA occurs when an API fails to properly check if a user is authorized to access or manipulate a specific object, such as a user account or transaction. This can allow attackers to access unauthorized data.

2. How can BOLA be prevented in API development?

Prevent BOLA by implementing server-side authorization checks, using unique and non-predictable object identifiers, and regularly testing for logic flaws using automated security tools like APIsec.ai.

3. Why is API security important for fintech applications?

APIs in fintech applications often handle sensitive financial data. Missing security controls, like those demonstrated in the Coinbase breach, can lead to massive data breaches, regulatory penalties, and loss of consumer trust.

4. How does APIsec.ai help prevent BOLA vulnerabilities?

APIsec.ai provides automated API security testing, continuously detecting BOLA and other vulnerabilities. It integrates with CI/CD pipelines to ensure proactive identification and remediation of API vulnerabilities before exploitation.

5. What is the role of error messages in preventing BOLA?

Error messages like “Source account does not match product ID” play a critical role in alerting users and systems to authorization failures, preventing unauthorized transactions from taking place.

‍