API Security · intermediate · ~10 min
Distinguish BFLA from BOLA and test for privileged-function access.
BFLA is missing role/function authorization: a low-priv user invokes admin/privileged endpoints or methods the API fails to gate. Test by calling privileged endpoints (and method variants) as a normal user. Fix: server-side role checks on every privileged function, deny by default.
BFLA yields privilege escalation through the API — performing admin actions or reaching management functions without authorization. With BOLA it forms the API authorization-bug core that dominates real-world API findings.
BFLA = function/role authZ gap. Privileged endpoints/methods uncheck. vs BOLA. Action/role (BFLA) vs object (BOLA). Test. Hit admin endpoints + method swaps as low-priv. Fix. Server-side role enforcement per function, deny by default; UI hiding ≠ control.
Where BOLA is about objects, BFLA is about functions/actions: a lower-privileged user invoking an endpoint meant for a higher role.
GET /api/v1/users/me ← any user
GET /api/v1/admin/users ← admin-only … but returns data to a normal user
DELETE /api/v1/users/5002 ← admin action a normal user can call
Or invoking an admin action via a method/parameter the UI hides from non-admins. The endpoint authenticates the caller but never checks their role/privilege for that function.
/admin, /internal, management verbs).Enforce function-level authorization server-side: every privileged endpoint and method checks the caller's role, deny by default. Don't rely on the UI hiding admin features — the API must enforce it.
BFLA is unauthorized access to privileged functions (vs BOLA's privileged objects); a normal user reaches admin actions the API didn't gate. The fix is server-side, per-function role authorization, never UI concealment.