OWASP Top 10 for APIs: A Practical Checklist for 2026
The OWASP API Security Top 10 is the industry reference for API vulnerabilities. But most articles just list definitions. This one gives you actual fixes — and tells you which ones you can check in 60 seconds without touching code.
OWASP's API Security Top 10 (updated for 2023, still the operative standard heading into 2026) is the closest thing to a universal API security checklist. Security auditors use it. Enterprise procurement teams ask about it. Compliance frameworks reference it. If your API is internet-facing, you should know where you stand on all 10.
The challenge: most OWASP guides describe what the vulnerability is without telling you what to do about it. This checklist does both. If you want to see these risks in action, the most common API security mistakes we find in real startups map directly to the OWASP categories below.
We've also marked which ones Scantient checks automatically in a 60-second external scan — no code access, no SDK, just your URL.
🛡️ Coverage summary: Scantient automatically checks 7 of the 10 OWASP API Security risks from the outside — API1, API3, API4, API7, API8, API9, and API10. The remaining three (API2, API5, API6) require authenticated testing or code-level review.
API1:2023 — Broken Object Level Authorization (BOLA)
What it is: An attacker changes an object ID in a request (/api/orders/1234 → /api/orders/1235) and gets back data that belongs to another user. The API doesn't verify that the requesting user owns the object.
Why it's #1: BOLA is the most common API vulnerability because it's invisible to code reviewers who focus on authentication — the user is authenticated, they're just accessing someone else's data. You only find it by testing object ownership, not just auth.
Fix: Every endpoint that returns data by ID must verify that the authenticated user owns or has explicit permission to access that specific object. This is a server-side check — not something you can enforce in the frontend. Use Row-Level Security (RLS) in Supabase/Postgres, or implement ownership checks in every resolver/handler.
How to check: Authenticated testing required — create two accounts, get an object ID from one, request it with the other. Scantient can detect patterns that suggest BOLA exposure (predictable sequential IDs, responses with other users' data fields) but full verification requires authenticated testing.
API2:2023 — Broken Authentication
What it is: Authentication mechanisms are flawed — weak tokens, missing token expiry, insecure credential transmission, or missing brute-force protection.
Fix: Use battle-tested auth libraries (NextAuth, Clerk, Auth0) instead of rolling your own. Enforce short JWT expiry (15–60 minutes for access tokens). Require refresh token rotation. Rate-limit authentication endpoints. Never transmit credentials in query parameters. Implement account lockout after repeated failures.
How to check: Partially automatable. Check for rate limiting on /api/auth/login (Scantient checks this). For token strength and expiry — use jwt.io to decode tokens and check exp claims.
API3:2023 — Broken Object Property Level Authorization (BOPLA)
What it is: APIs return more fields than the user should see (Excessive Data Exposure) or allow users to update fields they shouldn't be able to modify (Mass Assignment). Both are BOPLA.
Why it happens: Developers return entire database objects to the frontend because it's easy. A user object containing email, name, and role gets returned — the frontend only shows name, but role is in the JSON response. An attacker sees it and knows your role values.
Fix: Define explicit output schemas (using Zod or similar) for every API response. Never return raw database objects. For write endpoints, explicitly allowlist the fields that users can modify — never use Object.assign(req.body, user) patterns.
How to check: Scantient scans API responses for fields that look like sensitive internal data — admin flags, internal IDs, other users' data patterns. It can't catch every case, but catches common over-exposure patterns.
API4:2023 — Unrestricted Resource Consumption
What it is: No limits on how many requests a client can make, how large requests can be, or how much server resource a single request can consume. This enables DoS attacks, bill fraud (especially on AI apps), and resource exhaustion.
Why AI apps are especially vulnerable: Every LLM inference call costs money. An API endpoint without rate limiting is a direct path to a $10,000 bill. See our deep dive on AI-specific API vulnerabilities for the full picture of how LLM endpoints raise the stakes.
Fix: Implement rate limiting on all endpoints (per-IP and per-user). Set maximum request body sizes. Implement query complexity limits on GraphQL. Set provider-level spending caps on all AI API accounts. Use X-RateLimit-* headers to communicate limits to clients.
How to check: ✅ Scantient checks this automatically. It probes endpoints for X-RateLimit headers and flags endpoints that accept user input without rate limiting signals as high-severity findings.
API5:2023 — Broken Function Level Authorization (BFLA)
What it is: Admin or privileged functions are accessible to regular users. The API doesn't verify that the caller has the permission level required to call the function — only that they're authenticated.
Fix: Separate admin endpoints from user endpoints structurally (e.g., /api/admin/* vs /api/*). Implement role-based access control (RBAC) at the middleware or handler level — not just in the frontend. Test every admin function with a regular user account.
How to check: Requires authenticated testing as a non-admin user. Scantient can detect admin endpoints that don't return 401/403 on unauthenticated requests, but testing with a regular user role requires session-level access.
API6:2023 — Unrestricted Access to Sensitive Business Flows
What it is: Business-critical flows (checkout, account creation, vote submission, referral redemption) can be automated and abused at scale because there are no anti-automation controls.
Fix: Implement CAPTCHA or proof-of-work on flows that should be human-only. Use device fingerprinting and behavioral signals to detect automation. Rate-limit by account, email, or IP on flows that have real business value per request. Monitor for statistical anomalies in high-value flows.
How to check: Testing requires business context — you need to know which flows are sensitive. Scantient checks for rate limiting signals on detected endpoints, but identifying which flows qualify as "sensitive business flows" requires a manual review of your application's business logic.
API7:2023 — Server-Side Request Forgery (SSRF)
What it is: Your API accepts a URL from a user and fetches it server-side — and an attacker supplies an internal network address (http://169.254.169.254/, http://localhost/) to access your internal infrastructure or cloud metadata services.
Why it's dangerous: AWS/GCP/Azure metadata endpoints at 169.254.169.254 return cloud credentials, instance roles, and internal configuration — all accessible from your server if you don't block SSRF. A successful SSRF attack against a cloud app can lead to full AWS account takeover.
Fix: Validate and allowlist URLs before fetching them server-side. Block requests to private IP ranges, loopback addresses, and cloud metadata endpoints. Use a URL validation library that handles bypass techniques (IPv6, URL encoding, DNS rebinding). Never forward the raw response from a server-side fetch directly to the user.
How to check: ✅ Scantient checks for SSRF exposure patterns — endpoints that accept URL parameters and reflect content, cloud metadata endpoint accessibility, and internal IP ranges in API responses.
API8:2023 — Security Misconfiguration
What it is: The API is configured insecurely — missing security headers, permissive CORS, verbose error messages, open debug endpoints, default credentials, or unnecessary HTTP methods enabled.
Fix: Set all 5 security headers (CSP, X-Frame-Options, HSTS, X-Content-Type-Options, Referrer-Policy). Lock CORS to specific origins. Return generic error messages — never stack traces in production. Disable debug endpoints before deploying. Disable HTTP methods not in use (TRACE, OPTIONS if not needed).
How to check: ✅ Scantient checks this comprehensively and automatically. Security headers, CORS policy, error verbosity, exposed debug endpoints, HTTP method enumeration — all checked in every scan. This is the most reliably automatable OWASP category, and where most apps fail their first scan.
API9:2023 — Improper Inventory Management
What it is: Old API versions, undocumented endpoints, and shadow APIs are left running and unmonitored. Attackers discover these endpoints (which often lack current security controls) and exploit them while the team doesn't even know they're live.
Why it's common: You ship /api/v2/users but forget to disable /api/v1/users. That v1 endpoint was written before your auth refactor and still accepts unauthenticated requests.
Fix: Maintain an API inventory — every endpoint, every version, its auth requirements and last-updated date. Decommission old API versions with explicit deprecation notices and hard cutoff dates. Use automated scanning to discover endpoints that aren't in your inventory.
How to check: ✅ Scantient crawls your deployed app and enumerates API routes, including version paths. It flags /v1/ endpoints that are still active when /v2/ exists, and endpoints that don't match documented routes.
API10:2023 — Unsafe Consumption of APIs
What it is: Your application consumes third-party APIs and trusts their responses without validation. If a third-party API is compromised or returns unexpected data, your app processes it blindly — potentially leading to injection attacks, data corruption, or incorrect business logic execution.
Why it matters in 2026: AI apps are especially exposed here. If your app calls OpenAI, Anthropic, or a data enrichment API and uses the response directly — a supply chain compromise of that API could inject malicious content into your users' responses.
Fix: Validate all third-party API responses against an explicit schema before using them. Never render raw API responses in your UI without sanitization. Treat third-party API data the same way you treat user input — untrusted until validated. Implement circuit breakers and fallbacks for third-party API failures.
How to check: ✅ Scantient checks for third-party API dependencies in your JavaScript bundle and network requests, and flags dependencies that are loading from CDNs or external origins without subresource integrity (SRI) checks.
Your 2026 OWASP API Security Checklist
Use this as your pre-launch audit list:
The 7 items marked “Auto-checked” are verified automatically by Scantient in every external scan. The 3 manual items require authenticated testing or code review — they're architectural decisions that can't be verified from outside your app.
Start with the 7 automatable items. Most apps fail 3–5 of them on the first scan. Fix those, then work through the architectural items with your code.
Check your OWASP API Security posture in 60 seconds
Scantient automatically checks 7 of the 10 OWASP API Security risks from outside your app — no code access, no signup required. See your score instantly.