BOLA & BFLA: The API Vulnerabilities Your WAF Will Never Catch — and How Runtime Enforcement Changes the Equation

What BOLA Is — and Why It's So Dangerous

Broken Object Level Authorization occurs when an API endpoint returns data for a specific resource — a user account, an order, a medical record, a bank transaction — without verifying that the requesting identity is authorized to access that specific object.

The request is syntactically valid. The authentication token is legitimate. The endpoint exists. The only thing wrong is a single field: the object identifier in the URL or body belongs to someone else.

# Legitimate request — user 4821 accessing their own profile
GET /api/v1/users/4821/profile
Authorization: Bearer <valid_token_for_user_4821>
→ 200 OK  {"id": 4821, "name": "Alice", "email": "alice@corp.com"}

# BOLA attack — user 4821's token accessing user 9003's profile
GET /api/v1/users/9003/profile
Authorization: Bearer <valid_token_for_user_4821>
→ 200 OK  {"id": 9003, "name": "Bob", "email": "bob@bank.com", "ssn": "XXX-XX-XXXX"}
   BREACH: Unauthorized data returned — no error, no log, no alert

From the WAF's perspective, both requests are identical. From the API gateway's perspective, both requests carry valid authentication. From the rate limiter's perspective, one request per object ID is normal traffic. Nothing in the perimeter stack can detect this.

Why BOLA Is So Prevalent

BOLA is widespread for a structural reason: most authorization frameworks check whether a user is authenticated to access an endpoint type, but leave object-level authorization to the application developer — who often forgets, cuts corners under deadline, or makes assumptions about what an attacker would bother to try. In a large API surface with hundreds of endpoints and dozens of object types, a systematic BOLA vulnerability can go undetected for years while being actively exploited.

What BFLA Is — and Why It's Even Harder to Detect

Broken Function Level Authorization occurs when an API exposes privileged or administrative functions that regular users — or AI agents — can call because access controls were applied inconsistently, incompletely, or not at all at the function level.

BFLA is not about accessing the wrong data object. It's about calling the wrong operation entirely.

# Standard user account — should only have read access
Token claims: {"role": "user", "id": 4821}

# BFLA attack — regular user calling admin endpoint
DELETE /api/v1/admin/users/9003
Authorization: Bearer <valid_token_for_regular_user_4821>
→ 200 OK  {"deleted": true}   ← Account deleted. No authorization error.

# BFLA via AI agent — over-permissioned agent calling privileged endpoint
POST /api/v1/internal/billing/override
Body: {"user_id": 9003, "charge": 0}
Authorization: Bearer <ai_agent_service_account_token>
→ 200 OK  ← Billing override executed. Agent was never supposed to reach this endpoint.

BFLA in the Age of AI Agents

BFLA has become dramatically more dangerous with the proliferation of AI agents. Agents are typically issued broad API credentials so they can flexibly access resources as the LLM decides they're needed. This means an agent service account often has access to many more API functions than any human user ever should — and if the agent is manipulated via prompt injection, it may call privileged functions with legitimate credentials that were never intended for that purpose.

The Detection Gap: Why Your Current Stack Misses Both

How ziriz.ai Detects and Prevents BOLA/BFLA at Runtime

ziriz.ai's patent-pending runtime sensor instruments the application at the process level — not at the network boundary. This gives it access to context that no perimeter tool can reconstruct:

BOLA Detection: Identity-to-Object Correlation

When a request arrives at an API endpoint, the ziriz.ai sensor simultaneously observes: the authenticated identity extracted from the JWT/token (user ID, role, tenant), the object ID being requested (from URL path, query parameters, or request body), and — critically — whether the application's own authorization logic validated that the requesting identity owns or has rights to that specific object.

This correlation happens at the runtime layer, inside the application's execution context — not by guessing from network packets. The result is zero false positives: ziriz.ai only fires a BOLA alert when it observes an authorization decision mismatch, not when it sees a suspicious-looking URL pattern.

BFLA Detection: Function-Level Access Policy

ziriz.ai enforces function-level access control policies via runtime hooks on the API routing layer. Policies are expressed as: "the user role may not invoke the /admin/* path family" or "the ai-agent service account may not call any endpoint tagged write-privileged." These policies are evaluated synchronously at the runtime layer — before the function handler executes, not after it returns a response.

# ziriz.ai BOLA detection event
[BOLA_DETECTED]
  endpoint:  GET /api/v1/users/9003/profile
  caller_id: user_4821 (from JWT sub claim)
  object_id: 9003 (from URL path param)
  ownership: MISMATCH — 4821 ≠ 9003, no admin role
  action:    BLOCKED — 403 returned before handler executed
  latency:   0.4ms

# ziriz.ai BFLA detection event
[BFLA_DETECTED]
  endpoint:  DELETE /api/v1/admin/users/9003
  caller_id: user_4821 (role: user)
  function:  admin:delete_user
  policy:    DENY — role 'user' cannot invoke admin:delete_user
  action:    BLOCKED — handler never called
  latency:   0.3ms

BOLA/BFLA in the AI Agentic Stack: The Amplified Risk

With AI agents now making API calls autonomously and at high frequency, the BOLA/BFLA risk surface has expanded by at least an order of magnitude. Consider the attack surface multiplication:

• Volume: A human user might make 50 API calls per session. An AI agent making tool calls in a reasoning loop might make 500 per minute. Systematic BOLA probing that would be obvious at human speed becomes statistically normal at machine speed.
• Scope: Agents are typically given access to a broad range of endpoints. A human user accesses their own data; an agent might legitimately access data across many users and systems, making the "is this authorized?" question much harder to answer without runtime context.
• Manipulation: Via prompt injection, an attacker can cause an agent to execute BOLA/BFLA attacks with the agent's own legitimate credentials — attacks that would never occur to the developer writing the agent's code and that no static policy could anticipate.

Runtime enforcement that correlates agent identity, object ownership, and function authorization — all simultaneously, at the process level — is the only architecture that can keep pace with this expanded risk surface.

Practical Steps: Hardening Against BOLA/BFLA Today

1. Audit every GET endpoint that accepts an object identifier (user ID, account ID, order ID, document ID) in the URL or body — and verify that each one explicitly checks whether the authenticated caller owns that object. Don't assume your framework does this for you.
2. Audit every write/delete/admin endpoint for whether function-level access controls are enforced server-side — not just hidden from the UI. Hidden endpoints are not protected endpoints.
3. Audit your AI agent service accounts. List every endpoint each agent credential can reach. For any endpoint the agent doesn't strictly need, remove access. Apply least-privilege aggressively.
4. Implement runtime authorization monitoring. Static audits catch known gaps. Runtime monitoring catches the gaps you haven't discovered yet — and the ones introduced in next week's deployment.
5. Test with an adversarial mindset at the object level. For every authenticated endpoint, ask: "What happens if I replace the object ID with another user's ID?" The answer should always be a 403 — but often isn't.