API Hacking Uncovered: Deep Dive into Broken Function Level Authorization (BFLA) and Broken Object Level Authorization (BOLA)

"With great API power comes great responsibility and even greater attack surfaces." - Uncle Ben in a parallel universe who worked in cyber security

APIs have become the backbone of modern web and mobile applications, offering flexibility, scalability, and interconnectivity. But with this convenience comes risk. Two of the most dangerous and commonly exploited vulnerabilities in APIs are Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA). These aren't just academic flaws, they’re real-world issues that attackers exploit to gain unauthorized access to data and functionality.

This blog dives deep into both BOLA and BFLA, comparing them, discussing breaches, and providing solid mitigation strategies.

API Security

What is Broken Object Level Authorization (BOLA)?

BOLA occurs when an API does not properly verify whether a user has permission to access or manipulate a specific object (resource). In essence, it allows unauthorized users to access or modify data simply by guessing or changing an object identifier (e.g., user ID, file ID).

APIs often use object IDs in URLs or request bodies, like this:

GET /api/users/12345/profile

If the API does not validate that the authenticated user is the owner of object 12345, then any authenticated user can change this ID and gain access:

GET /api/users/67890/profile

If the backend fails to verify object ownership, it results in privilege escalation.

Real-World Example: Instagram BOLA Bug (2019)

A researcher discovered that simply modifying the 'user_id' parameter in Instagram’s private APIs could return sensitive profile details of other users, including private information. Facebook (Meta) acknowledged it as a critical BOLA flaw and awarded a bug bounty.

What is Broken Function Level Authorization (BFLA)?

BFLA occurs when an API exposes sensitive functions (like admin-level actions or restricted endpoints) without proper authorization checks. It’s not about the object, it's about the action being performed on it.

Suppose the frontend hides an "admin-only" feature from normal users. But if the endpoint is still publicly accessible like:

POST /api/admin/deleteUser

...and the server doesn’t verify whether the user is an admin, then attackers can invoke admin-level functions without needing frontend access, just by crafting the request manually.

This leads to privilege escalation since a standard user can act like an administrator.

Real-World Example: GitHub Gist Deletion BFLA (2020)

A flaw in GitHub’s Gist service allowed users to delete other users’ gists by calling an internal admin endpoint directly. The frontend UI had no delete button for unauthorized users, but the backend failed to enforce function-level restrictions.

Common Attack Patterns and Exploitation

BOLA Attack Steps

1. Authenticate as a low-privilege user.

2. Intercept the API request.

3. Modify object ID or resource identifier.

4. Replay the request.

5. Access unauthorized data.

Tools Used: Burp Suite, Postman, OWASP ZAP

BFLA Attack Steps

1. Identify hidden or undocumented API endpoints.

2. Forge a request manually (even without UI support).

3. Skip or manipulate authorization headers.

4. Trigger the function and observe response.

Tools Used: Proxy tools, API fuzzers

API Hacking Mitigation Strategies

For BOLA

• Enforce object-level access control on the server-side for every request.

• Implement access control checks after authentication and before any object fetch.

• Avoid trusting user-supplied object IDs, instead use tokenized or hashed references if possible.

• Log and monitor access attempts for unexpected object IDs.

For BFLA

• Define authorization policies for every function and route.

• Don’t rely solely on frontend UI for restricting access.

• Use Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

• Leverage API gateways with built-in authorization filters.

Standards and Reference

• OWASP API Security Top 10

  • BOLA is ranked 1 (Broken Object Level Authorization)

  • BFLA is ranked 5 (Broken Function Level Authorization)

• OAuth2 for token-based access enforcement

• OpenAPI/Swagger for API documentation and ensure it doesn’t leak sensitive routes

Both BOLA and BFLA are subtle, dangerous, and surprisingly common in modern APIs and overlooking these API hacking techniques can be catastrophic.

Security isn’t just about authentication, it’s about authorization done right.

So next time you're designing an API, think like an attacker:

• Can someone change an ID and access something they shouldn’t? (BOLA)

• Can a normal user call a powerful endpoint they weren’t supposed to? (BFLA)

If yes, then your API is leaking more than just data, it’s leaking power.

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don’t forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let’s keep the conversation going and make cybersecurity a community effort!

-AJ