Broken Function Level Authorization

• OWASP
• Broken Function Level Authorization

API Security: Function Level Authorization

In today’s app-driven world, APIs are the backbone of everything. But if your API security is weak, you might as well be handing hackers a VIP pass. In this API Security 101 series, we’re breaking down common API flaws, why they happen, and how to lock ‘em down.

You’ve probably heard of the OWASP Top 10 for web security. Well, APIs got their own hit list—the OWASP API Security Top 10, featuring these usual suspects:

• Broken Object Level Authorization
• Broken User Authentication
• Excessive Data Exposure
• Lack of Resources & Rate Limiting
• Broken Function Level Authorization
• Mass Assignment
• Security Misconfiguration
• Injection
• Improper Asset Management
• Insufficient Logging & Monitoring

Today, we’re zooming in on OWASP API Security #5: Broken Function Level Authorization. Let’s get into it.

What’s the Deal with Broken Function Level Authorization?

Before we go deep, you might wanna check out my post on OWASP API Security Broken Object Level Authorization. Quick recap: APIs expose object identifiers to grant access, and if the right controls aren’t in place, attackers can snatch what ain't theirs.

Now, Broken Function Level Authorization is a whole different beast. This flaw lets unauthorized users perform restricted actions—think regular users doing admin-level stuff. It happens when apps don’t enforce strict function-based access control, either due to bad config or straight-up missing checks.

That means someone could edit, delete, or access admin functions just by tweaking their request. Let’s check out some real-world screw-ups.

Example 1: Hijacking Someone’s Post

Say an API lets users fetch blog posts like this:

GET /api/v1.1/user/1337/posts?id=32

That’s cool—public posts should be viewable. But what if the API doesn’t check permissions for DELETE and PUT methods? Then any random user could do this:

DELETE /api/v1.1/user/1337/posts?id=32

Boom. Someone else’s post just vanished. Not a good look.

Example 2: Playing Pretend as an Admin

Imagine a platform where admins manage user posts through special API requests:

DELETE /api/v1.1/user/1337/posts?id=32
POST /api/v1.1/user/1337/posts?id=32
PUT /api/v1.1/user/1337/posts?id=32

The system “knows” it’s an admin by checking a request header:

Admin: 1

See the problem? If an attacker slaps Admin: 1 onto their request, congrats—now they’re an admin. If access control isn’t enforced properly, you just gave them the keys to the kingdom.

Example 3: Security Through Obscurity Ain’t It

Now picture an admin-only endpoint for site stats:

GET /api/v1.1/site/stats/hd216zla

No user authentication, no role checks, just a long, weird-looking URL string. The devs might think, “Nobody will guess this.” Spoiler: someone will guess it. If an attacker stumbles upon this URL, it’s game over.

How Bad Can It Get?

The impact of Broken Function Level Authorization depends on what’s exposed. Attackers could:

• Impersonate other users
• Access restricted data
• Modify accounts that ain’t theirs
• Take full admin control

Yeah, it’s that bad. So what’s the move? Enforce strict role-based access control (RBAC) across all API functions. No shortcuts, no weak checks based on headers or parameters. Lock it down properly or risk getting wrecked.

Stay sharp, stay secure.