OWASP API Security Top 10 (2023) — Authorization Is the Whole Game

The 2023 revision of the OWASP API Security Top 10 is a meaningful improvement over the 2019 list. It accepts what every appsec engineer working with modern APIs already knew — broken authorization is the dominant API failure mode — and it adds Broken Object Property Level Authorization (BOPLA) as a distinct, frequently-missed risk.

This piece is the field-grade reading of the 2023 list. It is written for the appsec engineer who has to triage API vulnerabilities on Monday morning and the CISO who has to decide where to spend the next quarter's appsec budget.

The 2023 list — and where it actually breaks

BOLA — and the test that always finds it

BOLA happens when an authenticated user can fetch or modify an object identified in the URL or body, simply by changing its identifier. The route is authenticated; the object is not authorized. Frameworks happily let this through because authorization is a programming pattern, not a default.

The reliable test: take any authenticated user A, replay every request, substitute the object ID with one belonging to user B, and check whether the API rejects. Run this in your contract tests, not just in your pentest.

# Pseudocode for a contract test that fails CI on a BOLA regression.

import pytest
from clients import api_client

@pytest.mark.parametrize("path", ROUTES_WITH_OBJECT_ID)
def test_bola_isolation(path):
    user_a = api_client.login("user_a")
    user_b = api_client.login("user_b")

    obj_a  = user_a.create_object()
    obj_b  = user_b.create_object()

    # User A must NOT be able to read user B's object
    resp = user_a.get(path.format(id=obj_b.id))
    assert resp.status_code in (403, 404), (
        f"BOLA: {path} returned {resp.status_code} for cross-user fetch"
    )

    # And the response body must not leak it on a 404 either
    if resp.status_code == 404:
        assert obj_b.secret_field not in resp.text

BOPLA — the bug your UI tests will never find

BOPLA is the property-level cousin of BOLA. The route is authorized. The object lookup is authorized. But the response object contains a property — say, internal_credit_score, owner_email, or hidden_admin_note — that the requesting user is not entitled to see. The UI never displays it. The API returns it anyway.

BOPLA escapes UI-driven test plans entirely because the testing surface is the response payload, not the rendered screen. The fix is response shaping at the API layer based on the requesting identity. The test is automated property allow-listing per role.

API6 — the business-flow abuse that rate limits cannot solve

API6 — Unrestricted Access to Sensitive Business Flows — is the entry that most cleanly maps to a fraud problem rather than a security problem. Account creation at scale, coupon enumeration, content scraping, gift-card balance probing, login enumeration — all are abuses of legitimate flows by adversaries who do not need to break authentication.

Rate limiting alone does not solve it. The defenses are behavioral: device fingerprinting, network reputation, IP / ASN clustering, sequence analysis, and friction proportional to risk (CAPTCHA, step-up, hold-for-review). Treat the most-abused flows as fraud surfaces with their own KPIs.

• 01Inventory the high-value flows: signup, login, password reset, coupon redemption, gift-card lookup, refund, balance check
• 02Instrument per-flow KPIs: success rate, friction injection rate, fraud chargeback or downstream-loss correlation
• 03Tier responses: low-risk → allow, medium → step-up, high → quarantine, certain → deny + investigate
• 04Replay flows from suspect ASNs / device fingerprints in shadow mode before enforcing — false-positive cost is high

API9 — discovery is the prerequisite for everything else

Improper Inventory Management is the entry CISOs underestimate the most. Across our 2024–2025 API security assessments, the gap between client-believed API count and discovered API count averaged 38%. The undocumented APIs carry disproportionate BOLA and BOPLA debt because no one tested them.

A real discovery program triangulates from at least three sources: traffic-layer (gateway / mesh / WAF logs), code-layer (route definitions in source repos), and observability-layer (APM / OpenTelemetry traces). The intersection is the inventory; the differences are the work.

The four KPIs that prove your API security program works

A 90-day uplift plan

1. 01Days 0–30 — Stand up triangulated API discovery (gateway + code + traces). Publish the inventory delta. Assign owners to every discovered shadow / zombie API.
2. 02Days 30–60 — Land BOLA + BOPLA contract tests in CI for the top 20 highest-risk routes. Gate merges on them. Expand coverage weekly.
3. 03Days 60–90 — Inventory the sensitive business flows (signup, refund, coupon, balance lookup). Stand up behavioral instrumentation in shadow mode. Publish the four board KPIs.

Closing — authorization is the whole game

Cryptographic mistakes are rare in modern APIs. Injection is largely solved by parameterized queries and ORMs. Authentication, while still a source of bugs, has good defaults in every major framework. Authorization remains custom code in every API and that is exactly why it remains the dominant failure mode. Invest your appsec dollars where the bugs actually live: object-level, property-level, function-level, and flow-level authorization. The 2023 OWASP API Top 10 finally tells you so without flinching.