OWASP Top 10 API Security Risks: What Changed in 2025

Why API security keeps getting harder

Unlike a traditional web application with a handful of forms and a login page, an API exposes its entire data model to anyone who can construct a valid request. Every endpoint is effectively a door, and most organizations we test have more doors than they can accurately count — undocumented internal endpoints, deprecated versions still running in production, and partner integrations nobody remembers approving.

Automated API discovery tools help build an inventory, but inventory is not the same as security. Knowing an endpoint exists tells you nothing about whether its authorization logic actually matches the business rules it was built to enforce.

Broken object level authorization is still #1

Broken Object Level Authorization (BOLA) has topped the OWASP API list for three revisions running, and for good reason: it is simple to introduce and expensive to miss. A developer builds an endpoint like `GET /invoices/{id}`, tests it with their own account, ships it, and never considers what happens when a user substitutes another customer's invoice ID.

What makes BOLA particularly dangerous is that it rarely triggers any alarms. There is no malformed payload, no injection string, no obvious signature for a WAF to catch — just a valid request for a resource the requester should not be able to see. That is precisely the class of vulnerability that requires a human tester who understands the data model, not a scanner running a fixed rule set.

The 2025 additions: unrestricted resource consumption and AI-adjacent risk

The updated Top 10 formalizes what many of us were already seeing in engagements: unrestricted resource consumption — APIs with no rate limiting, no payload size caps, and no cost controls on expensive operations like search or export. As more products bolt LLM-backed features onto existing APIs, an uncapped endpoint that triggers a model inference call can turn into a very expensive denial-of-wallet attack, not just a denial-of-service one.

We are also increasingly finding API endpoints that exist purely to feed data into an AI agent or chatbot, built without the same authorization scrutiny applied to the "real" customer-facing API. If your agent has broader read access than your web app does, that gap is not incidental — it is a new class of BOLA.

How manual testing catches what scanners miss

Automated tools are excellent at flagging missing security headers, outdated TLS configurations, and known CVEs in dependencies. They are far weaker at reasoning about business logic — the sequence of otherwise-valid calls that, combined, let an attacker reach data or functionality they should never touch.

In a recent engagement, our team chained three individually low-severity findings — a predictable ID scheme, a missing ownership check on a "download" endpoint, and an overly permissive CORS policy — into a full account takeover path. No single scanner flag would have represented that risk accurately; only manual exploitation demonstrated the real business impact.

Building a remediation-first testing program

A one-time penetration test tells you where you stood on the day of the assessment. A remediation-first program treats that report as the start of a cycle, not the end of one: findings get triaged with engineering, fixes get shipped, and — critically — a retest confirms the fix actually closed the gap rather than just changing its shape.

• Map every endpoint to the object types and ownership rules it should enforce, before testing begins.
• Test authorization from the perspective of a legitimate low-privilege user, not just an unauthenticated attacker.
• Apply rate limiting and cost controls to any endpoint that triggers a paid third-party call, including LLM inference.
• Retest after every fix — a patched endpoint with a new edge case is still a vulnerable endpoint.