OWASP API Security Top 10 (2023): Every Vulnerability Explained With Fixes
Six of the ten OWASP API Security Top 10 vulnerabilities involve technically valid requests. The attacker has real credentials, calls real endpoints, and gets real data back. No exploit kit required.
That's what makes API security different from traditional web application security. You can't block your way out of these issues. You have to build authorization logic correctly from the start.
This guide covers every category in the OWASP API Security Top 10 (2023 edition), what each vulnerability is, how attackers exploit it, real-world examples, and exactly how to prevent it. By the end, you'll have a working checklist for auditing your own APIs.
What Is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a ranked list of the most critical API vulnerabilities, maintained by the Open Web Application Security Project (OWASP). The list draws from real-world penetration testing data, bug bounties, and security research.
The current edition was published in 2023. It replaced the 2019 list, adding three new categories and consolidating two others.
Who should use it:
- Backend and full-stack developers building APIs
- Security engineers running API security programs
- DevSecOps teams integrating security into CI/CD
- CTOs at startups preparing for SOC 2 or PCI DSS compliance
The OWASP API Top 10 is not the same as the OWASP Web Application Top 10. The Web Application list targets browser-based vulnerabilities like XSS and insecure deserialization. The API list focuses on authorization logic failures, business flow abuse, and behavior-based vulnerabilities that rule-based scanners miss.
What Changed in the OWASP API Top 10 for 2023
The 2023 update made meaningful structural changes. Here's what moved:
| Change | Detail |
|---|---|
| BOLA renamed | "IDOR" became "Broken Object Level Authorization (BOLA)" |
| Two categories merged | "Excessive Data Exposure" + "Mass Assignment" became API3: BOPLA |
| Three new categories added | API6 (Business Flows), API7 (SSRF), API10 (Unsafe Consumption) |
| Two categories dropped | Insufficient Logging and Monitoring, Injections (consolidated elsewhere) |
The most significant shift is the addition of API6, Unrestricted Access to Sensitive Business Flows. This category reflects a hard truth: many API attacks aren't bugs at all. The API works exactly as designed. Attackers just abuse it at scale.
API1:2023, Broken Object Level Authorization (BOLA)
BOLA has held the number one spot on every OWASP API list since 2019. It's the most common, most exploited, and hardest to catch automatically.
What It Is
BOLA occurs when an API accepts an object ID as input but doesn't verify whether the requesting user owns or has permission to access that object.
GET /api/v1/trips/48291
Authorization: Bearer <driver_token>
If the API returns trip details for any driver simply by changing the ID, without checking ownership, it's vulnerable to BOLA.
Why Scanners Miss It
Traditional scanners look for error codes and known payloads. BOLA returns HTTP 200 with valid data. There's no error to catch. Detection requires testing with two separate user accounts and comparing whether Account B can access Account A's resources.
Real-World Example
A social platform's data-sharing API exposed 50 million user profiles because a developer assumed sequential object IDs weren't guessable. They were. Automated scraping collected the entire dataset in under 24 hours.
How to Prevent BOLA
Always enforce ownership at the data layer, not just at the route level:
# Vulnerable
def get_trip(trip_id):
return db.query("SELECT * FROM trips WHERE id =?", trip_id)
# Secure
def get_trip(trip_id, current_user_id):
trip = db.query("SELECT * FROM trips WHERE id =?", trip_id)
if trip.driver_id!= current_user_id:
raise Forbidden("Access denied")
return trip
Prevention checklist:
- Never rely on obscurity (UUIDs don't fix BOLA, they just slow brute force)
- Enforce object-level authorization at every endpoint, including
GET,PUT, andDELETE - Test with two accounts before every release, see our IDOR and BOLA testing guide
API2:2023, Broken Authentication
Broken authentication covers every way an API fails to properly verify who is making a request. It's in second place because the attack surface is wide and the mistakes are common, even among experienced teams.
What It Is
Authentication failures fall into several categories:
- No rate limiting on login or token endpoints
- JWT tokens accepted with
{"alg":"none"}(meaning no signature required) - JWT expiration not validated after token issuance
- Authentication tokens passed in URLs (exposed in server logs)
- Sensitive account changes (email, password) allowed without re-authentication
- Service-to-service calls between microservices with no authentication at all
Real-World Example
A GraphQL API allowed query batching without rate limits. An attacker sent a single HTTP request containing 500 login attempts by nesting them in one batch query. Standard rate limiting, which checks per request, never triggered. The attacker ran credential stuffing at full speed.
How to Prevent Broken Authentication
- Rate limit by IP and by account identifier, not just by request
- Validate JWT signature algorithm explicitly, never accept
alg: none - Set short expiration times on access tokens (15–60 minutes)
- Use refresh tokens with rotation on every use
- Always re-authenticate before sensitive account changes
API3:2023, Broken Object Property Level Authorization (BOPLA)
BOPLA combines two vulnerabilities from the 2019 list: Excessive Data Exposure and Mass Assignment. They share the same root cause, the API doesn't control which object properties a user can read or write.
The Two Forms
Excessive Data Exposure: The API returns more data than the client needs. A user profile endpoint returns {"name": "...", "email": "...", "internal_role": "admin", "ssn": "..."}. The frontend filters what's displayed, but the full payload is visible in the network tab.
Mass Assignment: The API accepts a JSON body and maps it directly to a database object without filtering. A user updates their display name but includes "role": "admin" in the payload. If the API doesn't strip unexpected fields, the role change sticks.
How to Prevent BOPLA
- Use explicit allow-lists for both input and output, never pass raw request objects to your ORM
- Define a response schema and strip fields that aren't in it before returning
- Apply property-level authorization checks, not just endpoint-level checks
API4:2023, Unrestricted Resource Consumption
APIs that don't limit how much compute, memory, or bandwidth a single request can consume are vulnerable to abuse, intentional or not.
Common Failures
- No rate limiting on compute-intensive endpoints (image processing, PDF export, ML inference)
- No maximum payload size on file upload endpoints
- No pagination limits on list endpoints (returning 100,000 records in one response)
- No query complexity limits in GraphQL (deeply nested queries that generate enormous database calls)
- Unlimited webhook registrations without validation
Real-World Impact
A financial API with no pagination limit on transaction history was queried for a single high-activity account. The response tried to return eight years of daily transactions with full metadata. The database query ran for 90 seconds and took down the service for other users.
How to Prevent It
- Set hard limits on payload size at the API gateway layer, not just in application code
- Implement pagination on every list endpoint and enforce a maximum
limitparameter - Add query depth and complexity limits to GraphQL APIs
- Monitor resource usage per client and set per-client rate limits
API5:2023, Broken Function Level Authorization (BFLA)
BFLA is often confused with BOLA. The difference: BOLA is about accessing another user's data. BFLA is about accessing privileged functionality you're not supposed to have.
What It Is
A standard user calls an admin endpoint:
DELETE /api/v1/admin/users/8827
Authorization: Bearer <standard_user_token>
If the API checks authentication (valid token) but not authorization (is this user an admin?), the delete succeeds.
Why It's Common
Many applications implement role checks at the UI level, the "Delete User" button only appears for admins. However, the underlying API endpoint has no authorization check of its own. Any user who knows or discovers the URL can call it directly.
How to Prevent BFLA
- Never rely on UI-level access control to protect API endpoints
- Apply explicit role checks at the controller or middleware layer on every sensitive route
- Audit admin endpoints specifically, they're the highest-value targets
API6:2023, Unrestricted Access to Sensitive Business Flows
This category is new in 2023, and it's the most conceptually important addition.
What Makes It Different
The vulnerability isn't in the code. The API works exactly as designed. Attackers use it faster and at a larger scale than any legitimate user would.
Real examples:
- Inventory hoarding: Bot scripts call a sneaker retailer's
POST /cart/addendpoint repeatedly at the moment of a product drop, buying all available inventory before legitimate customers complete checkout - Referral fraud: Automated account creation through a registration API generates thousands of fake accounts, each claiming a $10 referral bonus
- Appointment slot abuse: Scripts call a booking API faster than any human could, locking all available slots and reselling them
How to Prevent It
Traditional security controls don't catch this. The solutions are business-logic specific:
- Device fingerprinting and behavior analysis to distinguish bots from humans
- CAPTCHA or proof-of-work challenges at high-value flow entry points
- Velocity limits based on business context (e.g., one checkout attempt per user per minute)
- Anomaly detection that flags usage patterns outside normal human behavior
API7:2023, Server Side Request Forgery (SSRF)
SSRF is also new in the 2023 edition, elevated because cloud-hosted APIs create a uniquely dangerous attack surface.
What It Is
SSRF occurs when an API accepts a URL as input and makes a server-side HTTP request to it without validating the destination.
POST /api/v1/import
{"source_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
In cloud environments, the AWS metadata endpoint at 169.254.169.254 is accessible from any EC2 instance. An attacker who can make the server request that URL receives the instance's IAM credentials, and with them, access to everything that role can touch.
Real-World Example
The Capital One breach in 2019 exposed 100 million customer records. The attacker exploited an SSRF vulnerability in a misconfigured WAF to query the AWS metadata service, extract IAM credentials, and then access S3 buckets containing financial data.
How to Prevent SSRF
- Validate and allowlist URL schemes and domains before making any outbound request
- Block requests to private IP ranges (
10.x.x.x,172.16.x.x,192.168.x.x,169.254.x.x) - Use network-level controls to restrict outbound traffic from API servers
- Don't use user-supplied URLs to fetch resources without validation
API8:2023, Security Misconfiguration
Security misconfiguration is the broadest category on the list. It covers every way an API is deployed incorrectly, even when the underlying code is fine.
Most Common Failures
- CORS misconfiguration:
Access-Control-Allow-Origin: *combined withAccess-Control-Allow-Credentials: true, this allows any website to make authenticated cross-origin requests on behalf of your users - Debug endpoints in production:
/debug,/console,/actuator,/swagger-uiexposed without authentication - Unnecessary HTTP methods: A read-only endpoint that also accepts
PUT,DELETE, andPATCH - Default credentials: API gateway or management console left with factory credentials
- Verbose error messages: Stack traces, database schema names, or internal paths returned to the client
- Missing TLS: API traffic sent over HTTP in any environment
How to Prevent It
Misconfiguration is hard to catch in code review because there's often no code to review, the problem is in infrastructure settings. Address it at the deployment layer:
- Run a security headers check as part of every deployment
- Disable or protect all debug and admin endpoints behind authentication
- Return generic error messages to clients and log details server-side
API9:2023, Improper Inventory Management
Shadow APIs, endpoints that exist but aren't documented or actively maintained, are one of the fastest-growing attack surfaces in modern applications.
What Creates Shadow APIs
- Deprecated versions left running:
/api/v1/is still live after/api/v3/launched, with fewer security controls - Undocumented internal endpoints: Developer convenience routes that were never removed from production
- Third-party integrations: External services given broader API access than they need
- Staging APIs accessible from the internet: Development environments with real or production-like data
How to Find Them
Your own tools can help: Chrome extension traffic monitoring, DNS enumeration, and traffic analysis often reveal endpoints your team didn't know existed. So can running API Discovery Extension against your own domains before attackers do.
How to Prevent It
- Maintain a complete API inventory, version, owner, deprecation date, access level
- Set hard deprecation timelines and enforce them, don't leave v1 running indefinitely
- Apply the same security controls to all active API versions, not just the latest
- Audit third-party integration scopes quarterly
API10:2023, Unsafe Consumption of APIs
The final category is also new in 2023. It addresses a risk that's grown alongside the proliferation of third-party APIs and microservices: your API may be secure, but a service it trusts may not be.
What It Is
Your application trusts the data it receives from a partner API. That partner API is compromised. The attacker injects malicious payloads into responses that your API processes and executes without validation.
Example scenario: Your application calls a third-party geolocation API to enrich user data. The geolocation provider's database is poisoned with SQL injection strings in city name fields. Your application inserts the city name directly into a database query without sanitization. The attack runs inside your infrastructure, originating from data you had no reason to distrust.
How to Prevent It
- Treat all third-party API responses as untrusted input, validate and sanitize before processing
- Use request signing to verify response integrity where the API provider supports it
- Maintain an inventory of all third-party API integrations and their data access scope
- Monitor third-party API responses for anomalies (unexpected fields, unusual values, schema changes)
How to Test Your APIs Against the OWASP API Top 10
Manual penetration testing is thorough, but it's expensive ($15,000–$40,000 per engagement) and runs infrequently. By the time you get results, your codebase has already moved on.
The more effective approach is automated API security testing on every deployment. Specifically, you need a scanner that:
- Tests authorization by context, BOLA requires two-account testing; most scanners only test one session
- Understands your API structure, OpenAPI/Swagger specs let a scanner know what endpoints exist and what valid inputs look like
- Integrates with your CI/CD pipeline, catching issues before merge is cheaper than fixing them after release
ApyGuard integrates with GitHub Actions, GitLab CI, and Jenkins to run OWASP Top 10 coverage on every pull request. It detects BOLA, broken authentication, BOPLA, SSRF, and misconfiguration automatically, without manual setup for each endpoint.
Start your free OWASP API security scan, no credit card required. Your first report takes under five minutes.
OWASP API Security Checklist
Use this before every release. Check each item against your API design and implementation.
API1, BOLA
- Every endpoint that accepts an object ID verifies the requesting user owns that object
- Authorization checks happen at the data layer, not just the route layer
- Tested with two separate user accounts on every data-access endpoint
API2, Broken Authentication
- Rate limiting applied per account and per IP on login and token endpoints
- JWT signature algorithm validated explicitly,
alg: nonerejected - Access token TTL set to 60 minutes or less
- Re-authentication required before sensitive account changes
API3, BOPLA
- Response schema defined and enforced, no extra fields returned
- Input allow-list applied before mapping request body to database models
- Admin/internal fields never returned to standard user roles
API4, Unrestricted Resource Consumption
- Pagination enforced on all list endpoints with a maximum
limitvalue - File upload endpoints have size limits enforced at the gateway level
- GraphQL query depth and complexity limits configured
API5, BFLA
- Admin and privileged endpoints have authorization checks independent of the UI
- Role checks applied at the controller or middleware layer on every sensitive route
API6, Business Flows
- Velocity limits set on high-value flows (checkout, registration, booking)
- Anomaly detection in place for usage patterns inconsistent with human behavior
API7, SSRF
- URL inputs validated against an allowlist of permitted domains and schemes
- Private IP ranges blocked at the network layer for outbound requests
API8, Misconfiguration
- CORS headers audited and
Allow-Credentials: truenever combined with a wildcard origin - Debug and admin endpoints removed or protected from public access
- Generic error messages returned to clients; full details logged server-side only
API9, Inventory Management
- All active API versions documented with owner and deprecation status
- Deprecated versions have a confirmed shutdown date
- Third-party integration scopes reviewed and minimized
API10, Unsafe Consumption
- All third-party API responses validated and sanitized before processing
- Third-party API integration inventory maintained and reviewed quarterly
Frequently Asked Questions
What is the difference between the OWASP Top 10 and the OWASP API Security Top 10?
The OWASP Top 10 covers web application vulnerabilities like XSS and SQL injection. The OWASP API Security Top 10 covers vulnerabilities specific to APIs, primarily authorization logic failures and behavior-based attacks. Many API vulnerabilities involve valid requests that return correct HTTP 200 responses, which traditional web scanners don't detect.
What is the most critical OWASP API vulnerability?
BOLA (Broken Object Level Authorization) has ranked first since 2019. It's prevalent, easy to exploit, and invisible to most automated scanners. Every API that accepts object IDs as parameters should be tested for BOLA before every release.
How do I test for BOLA?
Create two test accounts. With Account A, create a resource and record its ID. With Account B, attempt to access that resource using the same ID. If the response returns Account A's data, the endpoint is vulnerable. Repeat this for every data-access endpoint in your API.
Does the OWASP API Security Top 10 apply to GraphQL?
Yes. GraphQL APIs are vulnerable to multiple categories. Broken authentication applies when query batching bypasses rate limits. Unrestricted resource consumption applies when deeply nested queries generate enormous database loads. BOLA applies when object-level authorization isn't enforced on resolvers.
How often should I run OWASP API security testing?
Run automated testing on every deployment. Supplement with a manual penetration test annually or before major releases, especially if you handle financial data, health information, or other regulated data types.
Which OWASP API vulnerabilities does ApyGuard detect automatically?
ApyGuard covers the full OWASP API Top 10, including BOLA detection through multi-session behavioral testing, broken authentication, BOPLA, misconfiguration, and SSRF. See our features overview for full coverage details.
Key Takeaways
The OWASP API Security Top 10 is not a static checklist, it reflects how attackers actually target APIs in production today. The 2023 update added three categories that reflect two real shifts: the rise of cloud-hosted APIs (SSRF) and the growth of business logic abuse (Business Flows, Unsafe Consumption).
A few patterns cut across most categories:
- Authorization logic belongs at the data layer, not the UI or route layer
- Automation is the only way to test consistently at development speed
- Third-party services are part of your attack surface, treat their data as untrusted input
The good news: most of these vulnerabilities are preventable with the right controls in place before code ships.
Published by Eren Kaan Çakır, ApyGuard | April 2026