#Quick Answer: What Is the OWASP API Top 10 and How Do You Test For It?
The OWASP API Security Top 10 (2023) is the industry-standard catalog of API risks — led by Broken Object Level Authorization (BOLA), broken authentication, and broken property-level authorization — and enterprise testing means validating each risk with authenticated, business-logic-aware tests rather than generic scans. Salt Security's H2 2025 report found 80% of real attack attempts align with this Top 10, yet 80% of organizations lack continuous API monitoring. A working program combines OpenAPI-driven testing, manual authorization checks, and a complete API inventory.
APIs are the front door of the modern enterprise, and most of them are guarded by a screen door. Every mobile app, partner integration, single-page frontend, and AI agent talks to your business through APIs — and attackers have noticed. Salt Security's H2 2025 State of API Security Report, surveying 386 professionals who manage APIs, found that one in three companies experienced an API security incident in the past year, half had to delay an application rollout over API security concerns, and only 19% are very confident in the accuracy of their API inventory. The OWASP API Security Top 10 (2023) gives enterprise teams a shared language for these risks; this guide turns each risk into a concrete testing playbook.
#API1: Broken Object Level Authorization — the Test Every Enterprise Misses
Broken Object Level Authorization, BOLA — the attack class formerly known as IDOR — has held the number one spot in both the 2019 and 2023 OWASP API lists, and for good reason. It is trivially easy to exploit and devastating in impact: the API authenticates you correctly, then trusts the object ID you send it. Change /api/v1/orders/1234 to /api/v1/orders/1235 and you are reading someone else's order, invoice, or medical record. Salt Labs' analysis of customer attack data found BOLA accounts for 27% of all API attack attempts — the second most exploited category after misconfiguration.
Testing for BOLA is straightforward but labor-intensive, which is why automation alone misses it. Create two test users with distinct data, authenticate as each, and attempt to access the other's objects across every endpoint that takes an identifier — path parameters, query strings, and request bodies. Don't stop at sequential integers: test UUIDs (they leak through other endpoints), test nested resources (/users/42/documents/7), and test write operations, not just reads. The most commonly missed variant is BOLA on batch endpoints, where a single request processes an array of object IDs and the authorization check covers only the first.
Remediation is architectural, not cosmetic. Every endpoint that touches an object must verify that the authenticated principal is allowed to touch that specific object, on the server side, on every request — never trust IDs from the client, and never rely on unguessable identifiers as a substitute for authorization checks. Centralize the check in middleware or a policy engine so individual developers can't forget it. Our SaaS API hardening guide documents the defense patterns — per-object authorization checks, indirect reference maps, and tenant-scoped queries — that belong in your secure coding standards.
#API2 and API3: Broken Authentication and Mass Assignment
API2, broken authentication, covers everything that lets an attacker become someone else: credential stuffing against login endpoints without rate limits, JWTs accepted without signature verification, tokens that never expire, and password reset flows that leak valid usernames. Testing starts with the authentication endpoints themselves: hammer /login and /token with throttled credential lists and confirm rate limiting actually engages, decode the JWTs your API issues and check the algorithm, expiry, and signature validation — the classic alg: none bypass still appears in enterprise code — and verify that logout actually invalidates the token server-side rather than just deleting it from the client.
API3, broken object property level authorization (BOPLA), merged two 2019 risks — excessive data exposure and mass assignment — into one of the most under-tested categories in the 2023 list. Mass assignment is the quieter killer: the user profile endpoint accepts a JSON body, and nothing stops you from adding "role": "admin" or "accountBalance": 99999 to it. Frameworks that auto-bind request bodies to model objects make this the default behavior, not the exception. Test every write endpoint by appending properties the UI never sends — role, isAdmin, tenantId, price, status — and confirm the API rejects or ignores them. On the read side, request objects and diff the response against what the UI displays; APIs routinely return full database rows including internal flags, hashes, and other tenants' data.
The fix for both is allow-listing. Bind only explicitly permitted properties on input, serialize only explicitly permitted properties on output, and treat the framework's default binding behavior as hostile until configured otherwise.
#API4 Through API7: Resource Consumption, Function-Level Auth, Business Flows, and SSRF
API4, unrestricted resource consumption, is the category teams dismiss as a performance concern until a $40,000 cloud bill arrives. Test pagination by requesting page sizes of 10,000 and absurd page numbers, upload maximum-size payloads to every file endpoint, and — for GraphQL APIs — send deeply nested queries and confirm depth and complexity limits engage. Missing limits enable both denial of service and data exfiltration at scale. Remediation is quotas, payload caps, and query cost analysis, enforced at the gateway so individual services can't opt out.
API5, broken function level authorization (BFLA), is BOLA's administrative cousin: the API checks that you are authenticated but never checks that your role may call the function. Enumerate every endpoint with a low-privilege token, especially anything under /admin, /internal, or /debug, and confirm each returns 403. The 2023 list kept this at number five unchanged from 2019 because the failure is so persistent — frontend hiding is not authorization, and "nobody knows this endpoint exists" is not a security boundary.
API6, unrestricted access to sensitive business flows, is new in 2023 and covers automated abuse of legitimate functionality: credential stuffing, carding, OTP brute force, and scalping. These flows are working as designed, which is exactly why scanners miss them. Test by automating the flow — can you attempt 1,000 OTP guesses, submit 500 checkout attempts, or scrape the entire catalog without triggering a defense? Mitigations are business-aware: flow-specific rate limits, device fingerprinting, CAPTCHA or proof-of-work on sensitive actions, and anomaly detection on flow velocity.
API7, server-side request forgery, also debuted in 2023. Any endpoint that fetches a URL — webhooks, file imports, PDF generators, avatar uploads — is a candidate. Test with URLs pointing at cloud metadata endpoints (169.254.169.254), internal hostnames, and redirect chains that start public and end private. Remediation is URL allow-listing, blocking private IP ranges at the egress layer, and disabling redirects on server-side fetches.
#API8 Through API10: Misconfiguration, Shadow APIs, and Unsafe Consumption
API8, security misconfiguration, is the single most exploited category in Salt Labs' data — 54% of all API attack attempts. It covers the unglamorous basics: verbose stack traces in error responses, missing security headers, default credentials on admin consoles, debug endpoints left enabled in production, overly permissive CORS, and TLS misconfiguration. Testing is largely checklist-driven, which makes it the highest-ROI automation target in the Top 10: run configuration audits against every environment on every deploy, diff staging against production, and treat any divergence as a finding. Misconfiguration is also where the 2023 list overlaps most with pipeline security — these are exactly the checks that belong in release gates.
API9, improper inventory management, is the category that makes the other nine untestable. You cannot secure APIs you don't know exist. Salt's H2 2025 data is damning: only 19% of organizations are very confident in their API inventory, while 54% rely on error-prone developer documentation to find sensitive data exposure. Old versions stay live without rate limits, internal endpoints get exposed through gateway misconfigurations, and acquired companies bring entire undocumented estates. Build the inventory from traffic, not documentation: discover APIs from gateway logs, cloud load balancers, and runtime discovery tools, then reconcile against what engineering claims exists. Retire deprecated versions aggressively — every old version is an untested attack surface.
API10, unsafe consumption of APIs, is new in 2023 and reflects a supply-chain reality: your API calls third-party APIs, and their responses are attacker-controlled input. Test integrations by pointing them at malicious mock servers — oversized responses, injection payloads in fields, redirect chains — and confirm your code validates, size-limits, and sanitizes everything it receives. Sign and verify exchanges where partners support it, and apply the same SSRF controls to outbound calls that you apply inbound.
#Building the Enterprise Testing Program: Tools, Cadence, and Coverage
Knowing the ten risks is table stakes; the enterprise differentiator is a program that tests them continuously. Start with the inventory — nothing else works without it — then layer four testing modes. First, shift security into the pipeline: run OpenAPI-driven DAST and contract tests against ephemeral staging environments on every release, with BOLA and BFLA test cases generated from the spec. Second, schedule quarterly manual penetration tests focused on business logic — the API6 flows and authorization chains that automation cannot reason about. Third, run continuous discovery and attack-surface monitoring in production, because APIs change between releases. Fourth, add runtime protection at the gateway for the threats testing can't fully eliminate, like credential stuffing and scraping.
Staffing matters as much as tooling. Authorization testing requires understanding the business — which objects belong to which tenants, which roles may do what — so pair security testers with product engineers during test planning, and recruit security champions inside API teams who own the BOLA checklist for their services. Measure what matters: percentage of inventoried APIs with passing authorization tests, mean time to remediate per risk category, and the count of deprecated versions still serving traffic. Report these to engineering leadership quarterly; what gets measured gets funded.
One structural trend belongs in every 2026 testing plan: AI agents are becoming API consumers. Agents call your endpoints with machine speed and machine creativity, which multiplies both legitimate load and the blast radius of an authorization flaw. Our AI agent security guide maps the OWASP agent risks onto this same testing discipline — if your APIs will serve non-human clients, test them with non-human thoroughness.
#Frequently Asked Questions
Is automated DAST enough to cover the OWASP API Top 10?
No. Automated DAST reliably covers API8 misconfiguration and parts of API2, API4, and API7, but BOLA, BFLA, BOPLA, and business-flow abuse require understanding your data model and authorization rules. Treat automation as the baseline that runs on every release and manual testing as the deep inspection that runs quarterly — Salt's data shows 80% of attacks align with the Top 10, and most of those need a human to find first.
How do you test BOLA without disrupting production data?
Test in staging with production-like data shapes, using dedicated test tenants whose data is clearly labeled and isolated. For production verification, limit tests to read operations on your own test accounts and never enumerate real customer IDs. Many enterprises also run BOLA test suites against production during approved windows with write operations pointed at canary objects that monitoring ignores.
How often should enterprise APIs be retested?
Every release gets automated testing in the pipeline; every API gets a manual authorization review at least quarterly and after any change to authentication, tenancy, or data models. High-risk APIs — payment, identity, anything with PII — deserve continuous testing and runtime monitoring. The Salt finding that 80% of organizations lack continuous monitoring is the gap to close first.
What's the difference between the OWASP API Top 10 and the regular OWASP Top 10?
The API Top 10 (2023) addresses risks specific to APIs: object and function-level authorization, mass assignment, business-flow abuse, and inventory management. The main OWASP Top 10 (2021, with a 2025 edition published) covers web application risks like injection, broken access control, and cryptographic failures. Enterprise teams need both — APIs have distinct threat models that the web list doesn't capture.
#Sources and Further Reading
- OWASP API Security Top 10, 2023 edition — the official list and category pages: OWASP
- OWASP API Security Top 10 overview and 2019-to-2023 changes: APIsecurity.io
- What's new in the 2023 list, with attack-scenario analysis: SCWorld
- Salt Security, H2 2025 State of API Security Report — 33% incident rate, 80% lacking monitoring, attack-technique breakdown: IT Security Guru