APIs are everywhere. Every mobile app, every SPA, every microservice communication, every IoT device — they all depend on APIs. And attackers know it.
In June 2023, the OWASP API Security Project released the second edition of the API Security Top 10, a major update to the original 2019 list. Three new risks were added (Unrestricted Access to Sensitive Business Flows, SSRF, and Unsafe Consumption of APIs), two were removed (Injection and Insufficient Logging & Monitoring), and several were consolidated.
Here are the ten most critical API security risks in 2023, what they mean, and how to avoid them.
API1:2023 — Broken Object Level Authorization (BOLA)
The risk: An API endpoint accepts an object identifier from the client (like a user ID, invoice number, or document key) and returns the corresponding object — without verifying that the caller is authorized to access it. Attackers simply iterate through IDs to access data that doesn’t belong to them.
This is the most common and most damaging API vulnerability. It consistently tops the list because it’s easy to introduce and hard to catch in code review.
What to do: Every function that accepts an object ID must verify the caller’s authorization to that specific object. Don’t rely on the client to tell you what they should see. Use randomized, unpredictable IDs (UUIDs) to make enumeration harder — but remember that’s a mitigation, not a fix.
API2:2023 — Broken Authentication
The risk: Weak or misconfigured authentication allows attackers to impersonate legitimate users. Common issues include weak password policies, credential stuffing susceptibility, missing multi-factor authentication, JWT secrets leaked in source code, and session tokens that don’t expire.
What to do: Enforce strong authentication for every API endpoint. Use standard, battle-tested authentication frameworks instead of custom implementations. Rotate and expire tokens. Require MFA for sensitive operations. Validate that tokens haven’t been tampered with on every request.
API3:2023 — Broken Object Property Level Authorization (BOPLA)
The risk: This is a new category that combines two risks from 2019: Excessive Data Exposure (the API returns more fields than the client should see) and Mass Assignment (the client can modify fields they shouldn’t control). The common root cause is the lack of property-level authorization.
A classic example: a PATCH endpoint for updating a user profile that also allows changing role or isAdmin because the framework auto-binds all request fields to the database model.
What to do: Never return or accept more properties than necessary. Use explicit allowlists for both response fields and bindable request properties. Don’t pass user input directly to ORM update methods.
API4:2023 — Unrestricted Resource Consumption
The risk: An API endpoint that triggers expensive operations — large database queries, image processing, email sending — without any limits on how often it can be called. Attackers can exhaust server resources, inflate cloud bills, or cause a denial of service.
What to do: Implement rate limiting per client and per endpoint. Set sensible timeouts for expensive operations. Use pagination for list endpoints. Monitor resource usage and alert on anomalies. Apply exponential backoff for retries.
API5:2023 — Broken Function Level Authorization (BFLA)
The risk: A regular user discovers they can call an administrative API endpoint by guessing the URL or by examining a frontend JavaScript bundle. If the endpoint doesn’t verify the caller’s role, the attacker gains admin-level access.
What to do: Enforce role-based access checks on every function, not just in the frontend. Never rely on hiding admin endpoints — a missing authorization check is a vulnerability regardless of whether the endpoint is “secret.” Test authorization logic with automated security tests.
API6:2023 — Unrestricted Access to Sensitive Business Flows
The risk: This is the newest addition to the list. It covers business logic abuse: automated ticket buying (scalpers), fake account creation, coupon abuse, and review spam. Unlike traditional vulnerabilities, these aren’t bugs — the API works exactly as designed, but the business impact of unlimited automated usage isn’t accounted for.
What to do: Identify business flows that would cause harm if automated — purchases, registrations, votes, comments. Add CAPTCHAs, rate limiting per user, device fingerprinting, and behavioral detection. Monitor for patterns that indicate automated abuse.
API7:2023 — Server Side Request Forgery (SSRF)
The risk: An API that accepts a URL and fetches it server-side — for profile images, webhooks, or document processing — can be tricked into making requests to internal systems. Attackers use SSRF to scan internal networks, access cloud metadata endpoints (like http://169.254.169.254/ on AWS), and reach services behind firewalls.
What to do: Validate and allowlist URLs that can be fetched. Block private IP ranges. Disable redirects. Use a dedicated, isolated network for outbound fetches with no access to internal services. Authenticate to cloud metadata services using IMDSv2 with a hop limit of 1.
API8:2023 — Security Misconfiguration
The risk: APIs are complex systems with many configuration surfaces: web servers, databases, authentication providers, cloud permissions, CORS policies, TLS settings, debug endpoints. Any of these can be misconfigured — and most are.
Common examples: CORS set to Access-Control-Allow-Origin: *, debug endpoints left enabled in production, verbose error messages exposing stack traces, default credentials unchanged.
What to do: Harden configurations against security benchmarks. Disable debug endpoints in production. Use automated scanners to detect misconfigurations in CI/CD. Apply least privilege to cloud permissions. Set strict, per-domain CORS policies.
API9:2023 — Improper Inventory Management
The risk: Most organizations don’t know how many APIs they have, let alone which versions are running, which endpoints are active, and which are deprecated. Old API versions with known vulnerabilities continue running alongside modern ones. Shadow APIs — undocumented endpoints added by individual teams — go unnoticed.
What to do: Maintain an inventory of every API, its version, its host, and its authentication requirements. Deprecate old versions with a clear sunset timeline. Discover shadow APIs through network traffic analysis. Document every endpoint — including its authorization model — in a machine-readable format (OpenAPI/Swagger).
API10:2023 — Unsafe Consumption of APIs
The risk: Your application is probably an API consumer itself — it calls payment gateways, identity providers, mapping services, AI models, and countless other third-party APIs. Developers tend to trust data from these third-party APIs more than direct user input, applying weaker validation and escaping. Attackers have noticed and are now targeting the supply chain: compromise a third-party API your app trusts, and the malicious response flows directly into your application logic.
What to do: Treat data from third-party APIs as untrusted input. Validate, sanitize, and escape it the same way you would user input. Pin specific API versions rather than accepting any response format. Monitor for unusual response patterns from third-party services. Have a plan for when a provider you depend on is compromised.
The shift toward API-first security
The 2023 update reflects a fundamental shift: API security is no longer just about finding implementation bugs. Three of the new additions — business flow abuse, SSRF, and unsafe API consumption — are architectural and design concerns. They require thinking about how APIs are composed, consumed, and automated, not just how they handle a single request.
The common thread across the entire list is authorization. Five of the ten risks (API1, API3, API5, API9, API10) are fundamentally about making sure each request accesses only what it should. The others are about resilience, configuration hygiene, and trust boundaries.
APIs are not web pages. They don’t render HTML, they don’t manage sessions the same way, and their attack surface is orders of magnitude larger. The OWASP API Security Top 10 is a useful starting point — but the real work is in building authorization thinking into every layer of your API design.
boring.tools helps you maintain an inventory of your software dependencies and track vulnerabilities across your supply chain — including the third-party APIs and packages your applications consume. See how it works →