Why OWASP API Top 10 Still Catches Engineering Teams Off Guard

Every year, security teams run API assessments. Every year, the same findings come back. Broken Object Level Authorisation. Excessive data exposure. Unrestricted resource consumption. The OWASP API Security Top 10 was published to help — but most engineering teams still ship these vulnerabilities. Here's why.

The Problem Isn't Awareness — It's Abstraction

Ask any senior engineer if they've heard of BOLA (Broken Object Level Authorisation) and most will say yes. Ask them whether their latest API endpoint validates that the requesting user actually owns the object they're accessing — and things get quieter.

The gap isn't knowledge. It's the translation from abstract vulnerability class to concrete implementation decision. OWASP API1:2023 — BOLA is easy to understand in theory. It's surprisingly easy to miss when you're three sprints deep building a microservices mesh with 40 endpoints.

API1 — Broken Object Level Authorisation (BOLA)

This remains the most exploited API vulnerability year after year. The pattern is always the same: an endpoint accepts a user-controlled ID and returns the resource — without checking whether the authenticated user is authorised to access that specific resource.

The fix sounds simple — validate ownership server-side on every request. In practice, this requires discipline across every endpoint, every sprint, with every new developer who joins the team. One missed check becomes a data breach.

API2 — Broken Authentication

Authentication failures in APIs are rarely about not having auth at all. They're about partial authentication — endpoints that check tokens on most routes but miss a few, token validation that doesn't verify the algorithm (alg: none attacks), or refresh token flows that don't expire properly.

The most common pattern I see in assessments: API gateways that enforce authentication at the perimeter but internal service-to-service calls that use no authentication at all. If an attacker can reach the internal network — through SSRF, misconfigured cloud infrastructure, or lateral movement — they have full unauthenticated access to everything behind the gateway.

API3 — Broken Object Property Level Authorisation

This one is newer to the Top 10 but has been around forever under different names (mass assignment, over-posting). The issue: APIs that accept more properties in a request body than they should, allowing attackers to set fields like role, isAdmin, or verified that were never meant to be user-controlled.

// Vulnerable — accepts all properties from request body
PUT /api/users/me
{
  "name": "Rakesh",
  "email": "[email protected]",
  "role": "admin"  // attacker-added
}

API4 — Unrestricted Resource Consumption

Rate limiting is one of those controls that everyone knows they need and few implement correctly. The typical failure: rate limits that apply per-IP (trivially bypassed with distributed requests), limits that only apply to authentication endpoints but not business logic endpoints, or no limits at all on resource-expensive operations like bulk exports or search queries.

Beyond DDoS risk, unrestricted resource consumption enables credential stuffing, enumeration attacks, and in some cases, direct financial damage to the organisation running the API.

Why Teams Keep Shipping These

The root causes are consistent across every team I've assessed:

• No API-specific threat model. Teams threat model the application but treat APIs as a transport layer rather than an attack surface in their own right.
• Authorisation is an afterthought. Authentication gets built first, authorisation gets bolted on later — or not at all for internal endpoints.
• No API security testing in CI/CD. SAST tools catch code patterns but miss runtime authorisation flaws. Without dynamic API testing in the pipeline, BOLA ships to production every time.
• Documentation lag. APIs are built faster than they're documented. Undocumented endpoints don't get reviewed. Undocumented endpoints get exploited.

What Actually Works

After running dozens of API security assessments, here's what moves the needle:

• Add BOLA/BOPLA to every code review checklist for any endpoint that accepts an ID parameter
• Use automated API fuzzing (OWASP ZAP, Burp Suite Pro, or purpose-built tools like APIsec) in your CI/CD pipeline
• Enforce allowlisting on request body properties at the framework level — never trust what comes in
• Treat your API schema as a security artefact — version it, review it, and flag every new field for authorisation impact
• Run an internal OWASP API Top 10 workshop — the abstract-to-concrete translation happens fastest in a room with your own codebase on screen

The Bottom Line

The OWASP API Top 10 isn't a checklist to run once a year before an audit. It's a map of where your APIs are most likely bleeding right now. The teams that take it seriously build API security into their development process — not as a separate security review, but as a design constraint from the first endpoint.

Attackers aren't waiting for your next pentest to find BOLA. They're running automated scanners across your public API surface today.