API Authorization Flaws (Broken Object Level & Function Level Auth)

 

API Authorization Flaws: BOLA and BFLA Explained for Real-World Security

APIs are the hidden pipes that keep modern apps running. Your banking app, ride sharing app, and social media feed all depend on APIs to send and receive data behind the scenes.

When those APIs make simple mistakes in authorization, private data leaks. You do not always need complex malware. Often, attackers just change an ID or call a hidden function. Two of the worst mistakes are Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA).

Both BOLA and BFLA appear in the OWASP API Security Top 10 that teams still follow as of 2025, based on the latest 2023 list, where BOLA is ranked number 1 and BFLA is number 5.

This post breaks down what these flaws are, how attackers abuse them, and clear steps your team can take to prevent them.

---

What Are API Authorization Flaws and Why Do They Matter?

Photo by Markus Winkler

To understand API authorization flaws, start with two simple ideas: authentication and authorization.

Authentication is about identity. It answers, “Who are you?” When you type your username and password, scan your fingerprint, or sign in with Google, you are proving your identity.

Authorization is about permission. It answers, “What are you allowed to see or do?” Even if you are logged in, you should not see someone else’s bank balance or use admin tools.

APIs must handle both. Every click or tap in a modern app turns into a request to an API. That request includes some proof of identity, like a token, and then it asks to read data or run an action. The backend should check both who you are and what you are allowed to touch for every single request.

When that second part breaks, you get authorization flaws. These are not rare edge cases. Broken authorization is one of the main causes of real data breaches today. Many attacks are as simple as changing an object ID in a URL or calling an endpoint that should have been admin-only.

The two most common and dangerous types are:

• Broken Object Level Authorization (BOLA), where users can access or change data that belongs to someone else.
• Broken Function Level Authorization (BFLA), where users can trigger powerful actions they should not have.

In the OWASP API Security Top 10 that teams rely on in 2025 (the 2023 version), BOLA sits at number 1 and BFLA at number 5. That should tell you how often they show up in real systems.

Authentication vs authorization explained in plain language

Think about going to a movie theater.

When you walk in and show your ticket, the staff checks that it is valid. That is like authentication. You proved you have a ticket and you are allowed in the building.

Your ticket also has a movie title, a time, and maybe a seat number. That part is authorization. It says which room you can enter and exactly where you can sit.

APIs work the same way. They need to check both that you have a “ticket” at all and that your ticket matches the exact data or action you are asking for. If they skip the second check, anyone with a ticket can sit in any seat.

How APIs use authorization checks on every request

Most web and mobile apps today are just front ends that talk to APIs. When you open your banking app and tap “Accounts,” the app sends something like:

“Here is user 123’s token. Please give me the list of accounts for this user.”

The backend should verify two things:

1. The token is valid and belongs to a real user.
2. The data that is about to be returned belongs to that user.

The same is true for actions. When you tap “Transfer money,” the backend should check that you are allowed to move funds from that account, not only that you are logged in.

A simple example is a social media app. When you load your profile, the API should return only your posts. When you try to delete a post, the API should check that you own that post. These checks must happen on the server for every object and every action, not just at login.

Why broken API authorization is a top OWASP risk in 2025

The OWASP API Security Top 10, whose 2023 version is still the main reference in 2025, lists BOLA and BFLA among the highest risks. BOLA is number 1, BFLA is number 5.

Attackers love APIs because they are predictable. Endpoints often follow patterns like /api/users/123 or /api/admin/settings. If the backend does not enforce strong access control, curious users can turn into attackers with a few small changes in requests.

The business impact is real:

• Personal data leaks
• Exposure of financial or health records
• Breach of contracts and privacy promises
• Legal trouble under privacy laws
• Lasting brand damage and loss of customer trust

All of that can start from a single broken check around data or actions.

Broken Object Level Authorization (BOLA): When Users Can See or Change the Wrong Data

Simple BOLA example: changing an ID to access someone else’s data

BOLA happens when an API lets users read or edit objects they do not own, just by changing an ID.

Picture an endpoint like:

GET /api/accounts/12345

You log in to your banking app, open your main account, and the app calls this endpoint. If the server only checks that your token is valid, and not that account 12345 is yours, there is a problem.

An attacker can:

1. Log in as themselves.
2. Open browser dev tools or a proxy tool and capture the request.
3. Change the account ID  12345 to 12346.
4. Send the request again.

If the API responds with someone else’s account data, you have a classic BOLA bug. The same pattern appears with:

• GET /api/users/42
• GET /api/orders/9001
• PUT /api/profile/42

Any time the client sends an ID and the server fails to check ownership, other users’ data is at risk.

Real-world impact of BOLA on privacy and compliance

BOLA is not just a technical glitch. It can expose:

• Personal data like names, emails, and addresses
• Financial details like balances or card tokens
• Health data in medical systems
• Private chats or photos in messaging apps

Privacy laws such as GDPR in Europe or HIPAA for health data in the US care a lot about unauthorized access. BOLA is almost a textbook example of “someone saw data they were not allowed to see.”

For a company, that can mean:

• Regulatory fines
• Expensive investigations and audits
• Class action lawsuits
• Long-term loss of user trust

All from what can look like “just an ID in the URL.”

How attackers find BOLA bugs with simple API testing

Attackers do not need special gear to find BOLA. The process is simple:

They log in like a normal user. Then they open browser dev tools, a proxy, or an API client. They look at every request, searching for object IDs in URLs, query strings, or JSON bodies.

Any time they see a pattern like /users/42 or "accountId": "12345"They try changing the value to a nearby ID. If the server responds with valid data that does not belong to them, they have found a BOLA.

Scripts and automated tools can speed this up. An attacker might script a range of IDs and collect every response. Weak access control means they can scrape large chunks of your database with very little effort.

Practical ways to prevent BOLA in your APIs

Always check object ownership on the server. For every read, update, or delete, confirm that the current user owns that object or has explicit rights.

Never trust client-side checks. Hidden buttons, gray fields, or JavaScript flags do not count as security. The backend must enforce access.

Avoid only predictable IDs when possible. Use UUIDs or other less guessable identifiers, but treat this as a defense in depth, not a fix by itself.

Use per-user filters in your queries. For example, query “orders where user_id = current_user_id” rather than “order by ID only.”

Add tests that ask, “Can user A access user B’s object?” Make these tests part of your regular automated suite.

Use standard access control libraries or frameworks instead of custom ad hoc checks scattered across the codebase.

Broken Function Level Authorization (BFLA): When Users Can Do Actions They Should Not

Every API function is a door: what BFLA looks like in real apps

If each object in your API is something users can see, each endpoint is a door to a feature.

Some doors are low risk, like “view your profile.” Others are high risk, like “delete any user account” or “change global settings.”

Examples of risky endpoints include:

• DELETE /api/users/12345 for deleting accounts
• POST /api/admin/settings for changing app-wide settings
• POST /api/refunds for issuing refunds

BFLA happens when any logged-in user can open those doors. Maybe the front end hides the admin button, but the endpoint still exists. A curious user can guess the URL, copy it from documentation, or see it in a JavaScript file.

If the backend does not check their role, the action works. At that point, a normal user can act like an admin.

How regular users become fake admins through BFLA flaws

Here is a common story.

A regular user logs into a web app. They notice an “Admin” menu flash for a second, then disappear. Their curiosity kicks in.

They open the browser’s network tab and look at the requests. They see that when the admin visits a settings page, the app calls POST /api/admin/settings with a JSON body.

The user copies that request, changes a field, and sends it with their own token. If the server only checks that the token is valid, and not that the user is an admin, the update works.

With this kind of flaw, a user can:

• Change other users’ roles to admin
• Turn paid features on or off
• Issue refunds or credits
• Export all user data
• Disable important security settings

BFLA is about actions, not just data. It turns normal users into fake admins with very simple tricks.

Preventing BFLA with roles, permissions, and secure routing

Start by defining clear roles. Common ones are user, support, and admin. Some apps also have roles like auditor or vendor.

Map which role can call which API function. For each endpoint, write down who should be allowed to use it and for what actions.

Enforce role checks on the server for every sensitive route. Never rely only on hidden buttons or disabled form fields in JavaScript.

Use a “default deny” mindset. New endpoints should be blocked for all roles until you explicitly allow them for the right ones.

Review access control regularly. Security and product teams should sit together, walk through critical flows, and confirm that the server really checks permissions.

Add tests that try to call admin or support endpoints with a low-privileged user. These tests will catch many BFLA issues before attackers do.

Conclusion

APIs power almost every app your users touch. When authorization breaks, trust breaks with it.

BOLA is about the wrong data, where users see or change objects they do not own. BFLA is about the wrong actions, where users can open doors that should be admin-only.

You do not need to fix everything at once. Start this week by reviewing a few key endpoints, like account views, profile updates, and admin tools. Add or tighten authorization checks where needed.

Small, steady improvements to access control can stop many high-profile breaches before they start, and keep your users’ data and your reputation safe.