APIs are the connective tissue of modern software. Every mobile app, SaaS product, and microservices architecture depends on them. They are also the fastest-growing attack surface: the Verizon 2025 Data Breach Investigations Report found API abuse present in over 40% of web application incidents. OWASP updated their API Security Top 10 list to reflect this reality, and every team building or running an API needs to know what is on it.

What is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a ranked list of the most critical security risks specific to APIs. Unlike the OWASP Web Application Top 10, it focuses on issues that arise from how APIs expose business logic, data, and functionality - risks that traditional web scanners often miss entirely.

The 2023 edition reflects how attack patterns have shifted as REST APIs replaced page-based web applications. Let us walk through each category.

API1: Broken Object Level Authorization (BOLA)

BOLA - also called Insecure Direct Object Reference (IDOR) - is the number one API risk for good reason. It happens when an API endpoint accepts a user-supplied identifier (like /api/orders/4821) and returns data without verifying the requesting user owns that object.

An attacker simply increments the ID in the URL and reads other users' data. This attack requires no special tools, no elevated privileges, and often no account at all - just a valid session and a working API call.

How to fix it: Implement object-level authorization checks server-side on every request. Never trust that the user's session is sufficient - verify they have permission to access the specific record they are requesting.

API2: Broken Authentication

Authentication endpoints are high-value targets. Broken authentication covers a range of issues: weak password policies, no rate limiting on login endpoints, predictable tokens, missing expiry on JWT tokens, or accepting tokens signed with alg: none.

A common example is a mobile app's password reset endpoint that accepts any 6-digit OTP with no rate limiting. An attacker can try all 1,000,000 combinations in minutes and take over any account they have the phone number for.

How to fix it: Rate limit all authentication endpoints. Use short-lived tokens. Validate JWT algorithms explicitly - never trust the algorithm declared in the token header. Implement account lockout and monitor for credential stuffing patterns.

API3: Broken Object Property Level Authorization

This is a newer addition that covers two related problems. The first is excessive data exposure: an endpoint returns far more fields than the client actually needs, and the client is expected to filter. This is dangerous because any field in the response is accessible to anyone intercepting or inspecting the API call.

The second is mass assignment: when an API binds all incoming request body fields to a server-side object without an allowlist, an attacker can set fields they should not have access to. Imagine a PUT /api/users/profile endpoint that accepts {"role": "admin"} because the API blindly updates all submitted fields.

How to fix it: Define explicit response schemas and never return more fields than the client needs. Use allowlists for mass assignment - explicitly list which fields can be set via user input, not which ones should be blocked.

API4: Unrestricted Resource Consumption

APIs that place no limits on how much a client can request are vulnerable to resource exhaustion. This includes missing rate limits, no pagination limits, no file size caps on uploads, and no timeouts on expensive operations.

Without rate limiting, a competitor or attacker can scrape your entire database via your public API. Without upload limits, a single request can consume all available disk space. Without timeout enforcement, a single slow query can exhaust your connection pool.

How to fix it: Implement rate limiting at multiple levels: per IP, per user, per endpoint. Set hard limits on page sizes and file uploads. Use timeouts on all external calls and database queries.

API5: Broken Function Level Authorization

While BOLA covers object-level access, this risk covers function-level access - administrative or privileged actions that are accessible to regular users because the API only checks authentication (are you logged in?) rather than authorization (are you allowed to do this?).

A typical example is an admin endpoint like DELETE /api/admin/users/{id} that returns 404 for unauthenticated requests but 200 for any authenticated user, including regular customers.

How to fix it: Apply role-based access control at every endpoint. Do not rely on endpoints being "hidden" or undocumented. Assume attackers will enumerate your API.

API6: Unrestricted Access to Sensitive Business Flows

Some API endpoints expose business logic that can be abused at scale when not protected by appropriate controls. Classic examples include checkout flows that can be exploited to purchase products at incorrect prices, referral systems that can be looped to generate unlimited credits, or review APIs that allow mass posting of fake reviews.

How to fix it: Identify your high-value business flows and add risk-specific controls: device fingerprinting, CAPTCHA for high-volume actions, anomaly detection for usage patterns that indicate automation.

API7: Server Side Request Forgery (SSRF)

SSRF occurs when an API fetches a remote resource specified by the caller without validating the URL. An attacker can supply an internal URL (http://169.254.169.254/ for AWS metadata, http://localhost:6379/ for Redis) and use the server as a proxy to reach internal services.

In cloud environments, SSRF is particularly dangerous because the metadata endpoint can return credentials used to authenticate to AWS, GCP, or Azure APIs.

How to fix it: Never fetch user-supplied URLs without validation. Use an allowlist of permitted domains. If the feature genuinely requires fetching arbitrary URLs, route requests through a dedicated egress proxy that blocks internal IP ranges.

API8: Security Misconfiguration

Security misconfiguration covers a wide range of issues that often stem from default settings left unchanged. Common examples include: CORS policies that accept any origin (Access-Control-Allow-Origin: *) on authenticated endpoints, verbose error messages that expose stack traces, debug endpoints left enabled in production, HTTP instead of HTTPS, or missing security headers like Content-Security-Policy and X-Content-Type-Options.

How to fix it: Define explicit CORS policies that list permitted origins. Strip stack traces from error responses in production. Disable debug and documentation endpoints in production environments. Automate security header checks as part of your CI/CD pipeline.

API9: Improper Inventory Management

Most organizations have more API versions, environments, and integrations running than they realize. Deprecated API versions that are still accessible, staging environments reachable from the internet, shadow APIs created by third-party integrations - all of these expand the attack surface without the security controls applied to the production API.

How to fix it: Maintain an API inventory. Enforce retirement of old API versions on a published schedule. Apply the same security controls to all environments. Monitor all API traffic, not just production.

API10: Unsafe Consumption of APIs

The final risk is often overlooked: your API may be trustworthy, but is it safely consuming third-party APIs? If your service trusts data returned by a third-party API without validation, an attacker who compromises the third party can inject malicious data into your system. This is a supply-chain risk at the API layer.

How to fix it: Treat data from third-party APIs as untrusted input. Validate and sanitize all incoming data regardless of source. Use TLS when calling external APIs and verify certificates.

How to detect API security issues automatically

Manual code review and penetration testing find API security issues but do not scale to continuous deployment workflows. Automated API security scanning addresses this gap.

Shieldome's API Security Scanner monitors your REST API endpoints weekly for OWASP API Top 10 risks. It probes for CORS misconfigurations, missing rate limiting, authentication bypass vectors, sensitive data exposure in responses, verbose error messages, JWT weaknesses, and dangerous HTTP methods - and generates a scored PDF report for each scan.

You can point it at your API's base URL for automatic endpoint discovery, or provide an OpenAPI/Swagger specification for more thorough coverage. The scanner operates passively - it probes for indicators of vulnerabilities without attempting exploitation, so it is safe to run against production APIs.

Key takeaways

API security is not a one-time audit. It is a continuous practice that requires the same discipline as functional testing - automated, systematic, and integrated into every release cycle.