What a BOLA attack actually looks like in your logs

Broken Object Level Authorization has topped the OWASP API Security Top 10 for years, and 2026 hasn't changed that. Industry breach analysis this year puts BOLA behind well over a third of all reported API vulnerabilities, and unlike SQL injection or a missing auth header, it doesn't show up in a static scan. It shows up in production, weeks after it started, usually because a customer noticed something was wrong before your monitoring did.

Why BOLA is invisible to normal security tooling

Every BOLA request is, on its own, a perfectly valid API call. Correct method, correct headers, valid auth token, 200 response. The only thing wrong is the object ID in the URL or payload — a user authenticated as account 4471 requesting the invoice, profile, or order belonging to account 4472. There's no malformed input for a WAF to flag and no signature for a scanner to match, because the vulnerability isn't in the code, it's a missing authorization check that only matters in context: is this specific user allowed to touch this specific object. Static analysis consistently misses it for exactly this reason — the flaw lives in business logic, not in a code pattern.

What it actually looks like in your logs

The tell isn't a single request, it's a shape across many. One authenticated user hitting an endpoint like /api/orders/{id} or /api/users/{id}/documents with a fast sequence of sequential or near-sequential IDs — far more than the handful of records that user's own account should ever touch. Attackers typically find these endpoints by watching their own legitimate traffic first, noticing the ID is predictable, then scripting a sweep. It's quiet, it's fast, and if you're only watching for failed logins and error-rate spikes, it never trips an alert, because every response is a 200.

Why this matters more now, not less

Two things have made BOLA a bigger problem this year rather than a solved one. First, the sheer growth of the API surface — every product ships an API before it ships a UI now, and mobile apps, partner integrations, and AI agents all talk to the same backend endpoints, often with less scrutiny than the browser-facing login flow gets. Second, AI-assisted development: as more endpoints get shipped faster with AI coding tools in the loop, object-level authorization is exactly the kind of contextual business rule that's easy for a fast-moving change to miss and easy for a reviewer to skim past, because the endpoint "works" in every test that matters to a functional review.

Detecting it without a security team

The reliable signal is behavioral, not signature-based: one authenticated identity accessing an unusual number of distinct object IDs on the same endpoint in a short window. That's a baseline computed from your own traffic — no threat intelligence feed required. In practice:

Watch object ID cardinality per session, not just request rate. A user making 200 requests a minute to their own dashboard is normal. A user touching 15+ distinct object IDs on the same endpoint in two minutes almost never is.

Fire on ratio, not raw volume. High-traffic accounts — support tools, admin dashboards — need a higher threshold than a typical customer account. A static rate limit either misses real attacks or drowns you in false positives.

Log the object ID, not just the endpoint. "Someone hit /api/orders 40 times" tells you nothing. "One user hit 40 different order IDs that aren't theirs" is the whole incident report.