Security Misconfiguration
OWASP API Security Top 10 · API8:2023
APIs inherit misconfiguration risk from the whole stack they run on — gateway, framework, container, orchestrator, and cloud platform — and add some of their own, such as permissive cross-origin policies, verbose error output, and unnecessary HTTP methods left enabled. The gateway is a particular concern because a single permissive rule there applies to every service behind it.
How it shows up in the real world
- A CORS policy reflecting arbitrary origins while allowing credentials.
- Detailed framework errors and stack traces returned to API consumers.
- Unnecessary HTTP methods such as TRACE or PUT enabled on production routes.
- Missing transport security or hardening headers on API responses.
- An unauthenticated management or metrics endpoint exposed alongside the API.
How to mitigate it
- Manage gateway, service, and platform configuration as reviewed code with automated policy checks.
- Restrict CORS to specific known origins and never combine wildcard origins with credentials.
- Disable unused methods, features, and endpoints, and require authentication on management interfaces.
- Return generic errors publicly and keep detail in internal telemetry.
- Re-scan configuration continuously rather than only at release.
Practice this topic
Test your knowledge of Security Misconfiguration with exam-style practice questions.
Rest of the API 2023 list
API1:2023Broken Object Level Authorization
The most common and most damaging API flaw. Endpoints take an object identifier from the caller and act on that object without confirming the caller is entitled to it. Because APIs expose identifiers as a matter of design, the entire dataset is often reachable by iterating a value, and the requests look completely legitimate in logs.
API2:2023Broken Authentication
Authentication mechanisms in APIs are often implemented per service and per endpoint, which is exactly the condition in which inconsistencies appear. Token validation may be incomplete, credential endpoints may be unthrottled, and machine-to-machine keys tend to be long-lived, broadly scoped, and rarely rotated.
API3:2023Broken Object Property Level Authorization
Even when access to an object is correct, access to individual fields may not be. This covers both directions: returning properties the caller should not see, and accepting properties the caller should not be able to set. It merges what earlier editions treated separately as excessive data exposure and mass assignment.
API4:2023Unrestricted Resource Consumption
Every API request consumes CPU, memory, storage, bandwidth, and often paid third-party calls. Without limits, a caller can degrade availability or run up costs simply by asking for a great deal, and the requests need not be malformed. Expensive operations such as search, export, report generation, and anything that fans out to other services are the usual pressure points.
API5:2023Broken Function Level Authorization
Where API1 is about which records a caller may touch, this is about which operations they may invoke. Administrative and privileged functions are frequently protected only by being undocumented or absent from the client, so a caller who guesses or observes the route reaches them. Changing an HTTP method on a known path is often enough.
API6:2023Unrestricted Access to Sensitive Business Flows
Some abuse involves no technical vulnerability at all: the API works exactly as designed, but automation lets one actor use a business flow at a scale the business never anticipated. Ticket purchasing, inventory reservation, promotional codes, and account creation are all technically valid operations that cause real harm when performed thousands of times by a script.
API7:2023Server Side Request Forgery
When an API accepts a URL and fetches it, the caller gains partial use of the server's network position. That position is usually far more privileged than the caller's own: internal services, cloud metadata endpoints, and administrative interfaces are reachable from inside. Features like webhooks, link previews, file import from URL, and PDF rendering are the usual entry points.
API9:2023Improper Inventory Management
You cannot protect what you do not know you are running. Organisations accumulate old API versions, staging deployments, forgotten integrations, and undocumented internal services, all of which stay reachable and stop receiving patches and review. Old versions are especially dangerous because they often predate the fixes and controls applied to the current one.
API10:2023Unsafe Consumption of APIs
Developers apply scepticism to user input and then extend implicit trust to responses from partner and third-party APIs. That trust is misplaced: an upstream service can be compromised, can be redirected, or can simply return something unexpected. Data arriving from another API deserves the same validation as data arriving from a browser.