OWASP API Security Top 10: What's Actually Breaking Production in 2026

There is no 2026 edition of the OWASP API Security Top 10 — the current, authoritative version remains the 2023 release — but that doesn't mean the list is stale. The same vulnerability class has held the #1 spot across both the 2019 and 2023 editions, and it's still responsible for roughly 40% of all API attacks observed in 2026 (Salt Security, Palo Alto Networks). The list isn't outdated; the industry simply hasn't fixed the top item yet.

The full list

The OWASP API Security Top 10 (2023) covers ten categories: Broken Object Level Authorization (API1), Broken Authentication (API2), Broken Object Property Level Authorization (API3), Unrestricted Resource Consumption (API4), Broken Function Level Authorization (API5), Unrestricted Access to Sensitive Business Flows (API6), Server-Side Request Forgery (API7), Security Misconfiguration (API8), Improper Inventory Management (API9), and Unsafe Consumption of APIs (API10) (Salt Security).

Why BOLA still wins

Broken Object Level Authorization happens when an API exposes object identifiers directly without verifying the requesting user is actually authorized to access that specific resource. The canonical example: an endpoint like /api/orders/456 directly exposes an order ID. If the API checks "is this user authenticated" but not "does this user own order 456," an attacker can simply increment or guess the ID to pull other users' data (DEV Community).

# Vulnerable: checks authentication, not ownership
@app.get("/api/orders/{order_id}")
def get_order(order_id: int, user: User = Depends(get_current_user)):
    return db.query(Order).filter(Order.id == order_id).first()

# Fixed: checks the resource belongs to the requesting user
@app.get("/api/orders/{order_id}")
def get_order(order_id: int, user: User = Depends(get_current_user)):
    order = db.query(Order).filter(
        Order.id == order_id,
        Order.user_id == user.id
    ).first()
    if not order:
        raise HTTPException(404)  # not 403 — don't confirm existence
    return order

The scale of the problem: BOLA/IDOR-class vulnerabilities are found and disclosed constantly even at mature companies — Meta's bug bounty program has paid out on multiple IDOR-class reports where improper authorization checks allowed unauthorized access to user-controlled resources (SQMagazine). More broadly, 62% of API breaches involve improper access controls allowing unauthorized data access, and attackers exploit predictable object IDs in more than 30% of API attacks (SQMagazine).

Object-level vs. function-level vs. property-level authorization

These three categories (API1, API3, API5) are easy to conflate but require different fixes, and testing one doesn't cover the others:

• Object-level (BOLA): "Can this user access this specific record?" — fixed by scoping every query to the authenticated user/tenant.
• Property-level: "Can this user read/write this specific field on a record they're otherwise allowed to touch?" — commonly missed on PATCH/PUT endpoints where a client can submit {"role": "admin"} alongside legitimate fields and the server blindly applies the whole payload (a mass-assignment problem, which OWASP treats as related but distinct).
• Function-level (BFLA): "Can this user call this endpoint at all?" — fixed by enforcing role checks at the route/controller level, not just hiding the button in the UI.

BOLA and BFLA together account for hundreds of distinct API vulnerabilities disclosed every quarter across the industry, underscoring that this isn't a rare edge case but a systemic gap in how authorization is implemented (Salt Security).

The newer entries: SSRF, shadow APIs, and third-party trust

Three categories added or elevated in the 2023 revision reflect how API attack surface has changed:

Server-Side Request Forgery (API7) matters more as APIs increasingly accept a URL parameter and fetch it server-side (webhooks, image imports, link previews) — an attacker can point that fetch at internal infrastructure (http://169.254.169.254/ cloud metadata endpoints, internal admin panels) instead of an external resource.

Improper Inventory Management (API9) — "shadow APIs" — covers old API versions, staging endpoints, or deprecated routes that are still live and reachable but no longer tracked or patched. An organization's actual attack surface is often larger than its documented one.

Unsafe Consumption of APIs (API10) flips the usual framing: it's not about securing your API, but about not blindly trusting data returned by APIs you call — a compromised or malicious upstream can inject malformed data your system then processes without validation.

A practical testing checklist

For each endpoint in an API surface, the minimum verification set:

1. Does this endpoint check resource ownership, not just authentication? (API1)
2. Does this endpoint allow updating fields the client shouldn't control? (API3)
3. Is there a rate limit and payload-size cap? (API4)
4. Can a lower-privilege role reach this endpoint directly, bypassing UI restrictions? (API5)
5. Does any endpoint fetch a caller-supplied URL server-side without allowlisting? (API7)
6. Are all API versions — including old/staging ones — documented and either patched or decommissioned? (API9)

Actionable takeaway

If you can only fix one thing this quarter, fix object-level authorization first — it's the single highest-yield target given it drives roughly 40% of API attacks, and the fix pattern is mechanical: every query that fetches a resource by ID must also filter by the requesting user's ownership or tenant scope, every time, with no exceptions for "internal" endpoints. Pair that with a runtime detection layer, since the majority of organizations currently have none and are relying on bug bounty reports or breach notifications to find out BOLA was exploited after the fact.

Sources: Salt Security — OWASP API Security Top 10, Palo Alto Networks, DEV Community, SQMagazine