OWASP API Security Top 10 (2023): A Practical Breakdown
Each of the ten categories with a real example of the vulnerability and a concrete mitigation — not just theory.
The OWASP API Security Top 10 was updated in 2023. If you're still referencing the 2019 list, some categories have changed. Here's each one with a realistic example of how it manifests and what you actually do about it.
API1: Broken Object Level Authorization (BOLA)
The most common API vulnerability. Your endpoint accepts a resource ID in the URL, looks it up, and returns it — without checking if the authenticated user owns it.
GET /api/invoices/7492 → returns invoice for userId 83
(but the requester is userId 12)
Fix: Every data-fetching query must include the authenticated user's ID as a filter. Never trust the ID in the request alone.
const invoice = await db.select().from(invoices)
.where(and(eq(invoices.id, invoiceId), eq(invoices.userId, session.userId)));API2: Broken Authentication
Weak token validation, no expiry, accepting tokens over HTTP, or allowing brute-force of credentials.
Fix: Use short-lived JWTs (15 min) with refresh tokens. Enforce HTTPS at the infrastructure level. Rate-limit login endpoints by IP and credential separately.
API3: Broken Object Property Level Authorization (new in 2023)
An endpoint returns an object, and some fields in that object should be hidden from the requesting user — but aren't. Or a write endpoint accepts fields the user shouldn't be able to set (mass assignment).
// Dangerous: spreads all request body fields onto the update
await db.update(users).set({ ...req.body }).where(eq(users.id, userId));Fix: Use an explicit allowlist of writable fields. Never spread request bodies directly into DB operations.
API4: Unrestricted Resource Consumption
No limits on request size, response pagination, or compute-intensive operations. A single request triggers nested DB calls or expensive computations.
Fix: Enforce max page size, max request body size, and execution timeouts. Use LIMIT in every paginated query.
API5: Broken Function Level Authorization
Admin-only endpoints are only "hidden" — not actually protected. An attacker who discovers /api/admin/users can access it.
Fix: Authorization checks must be in the handler, not just in the UI. Middleware should verify role on every admin route.
API6: Unrestricted Access to Sensitive Business Flows
The API correctly authenticates and authorizes but allows a flow to be abused at scale: bulk account creation, automated coupon redemption, scraping product data.
Fix: Layer business logic limits on top of auth: one promo code per account, device fingerprinting, CAPTCHA on suspicious patterns.
API7: Server Side Request Forgery (SSRF)
Your API accepts a URL from the user and fetches it server-side. An attacker supplies http://169.254.169.254/latest/meta-data/ (AWS IMDS) or internal service addresses.
Fix: Validate URLs against an allowlist of permitted domains. Block private IP ranges and cloud metadata addresses before making any outbound request.
API8: Security Misconfiguration
Default credentials, unnecessary HTTP methods enabled, verbose error messages exposing stack traces, CORS set to *, debug endpoints exposed in production.
Fix: Disable TRACE and OPTIONS where not needed. Never return stack traces to clients. Set CORS to explicit origin lists.
API9: Improper Inventory Management
Shadow APIs: old versions (/v1/) still running alongside /v2/, internal APIs reachable from the internet, third-party integrations with broader access than needed.
Fix: Sunset old API versions with deprecation headers. Document every exposed endpoint. Audit regularly.
API10: Unsafe Consumption of APIs
Your service calls a third-party API and trusts its response unconditionally — deserializing arbitrary payloads, following redirects without limits, rendering HTML from external responses.
Fix: Validate and sanitize third-party responses the same way you'd treat user input. Set strict timeouts. Never embed unescaped third-party content in responses.
The pattern across all ten is the same: never trust the client, validate at every layer, and enforce authorization in the code — not just the UI. ApiShield's threat model scanner flags violations in categories 1, 3, 4, and 8 during static analysis of OpenAPI specs.