API security is the practice of protecting the channels that let one program request data or actions from another. That channel is called an API (application programming interface), for example the one a mobile banking app uses to ask the bank's server for account data. The OWASP API Security Top 10 is a list of ten API risks published by OWASP, a community focused on application security. This article explains all ten in plain language, with ways to defend against them.

What an API is, and why it gets attacked

An API works by question and answer. A client program sends a request to an address called an endpoint, and the server replies with data. A made-up example is the request GET /orders/1001, which asks for order number 1001. That number is an object ID, a code that points to one record. Each endpoint must decide for itself whether the caller may see that record.

APIs are attractive targets because programs can call them directly. An attacker does not click through screens, and a script can send thousands of requests. The app's screen cannot hide a weakness either, because an attacker can send requests without using the screen at all.

The OWASP API Security Top 10 (2023 edition)

The newest edition listed on the project website (checked on 27 October 2026) is the 2023 edition, and we found no announcement of a newer one. The ten items are:

  • API1:2023 Broken Object Level Authorization: the API does not check that the caller may use that record, so changing the ID in a request returns someone else's data
  • API2:2023 Broken Authentication: login, password recovery or tokens (data that stands in for the user after login) can be abused, for example unlimited password guessing
  • API3:2023 Broken Object Property Level Authorization: no check at field level, so secret fields are returned or users can change fields they should not
  • API4:2023 Unrestricted Resource Consumption: no limit on the resources a request may use, so the system fails or costs spike
  • API5:2023 Broken Function Level Authorization: no check that the user may call that function, for example an ordinary user calling an administrator function
  • API6:2023 Unrestricted Access to Sensitive Business Flows: business steps such as buying or booking are automated by scripts until the business is harmed
  • API7:2023 Server Side Request Forgery: the API fetches a URL supplied by the user without checking it, so an attacker uses the server to reach internal systems
  • API8:2023 Security Misconfiguration: insecure defaults, or features left on that are not needed
  • API9:2023 Improper Inventory Management: the organization does not know which API hosts and versions it has, so forgotten old ones stay online
  • API10:2023 Unsafe Consumption of APIs: data from a third-party API is trusted more than data from a user

In the 2023 edition, API3 covers two issues that used to be separate: returning more data than needed (excessive data exposure) and letting users change fields they should not (mass assignment). The list is a starting point for review, not a catalog of every weakness, so use it together with testing and other standards.

Authorization problems: API1, API3 and API5

These three are one problem at three levels. The first level is a single record (object), such as one order. The second is a field (property) inside that record, such as price or status. The third is a function, such as issuing an administrator invitation. All three levels must be checked on the server for every request.

INFOGRAPHIC
Three levels of authorization to check on every request
API request
check on the server every time
Single record (API1)
change the ID, see another's data
Field in a record (API3)
over-exposed or editable fields
Function (API5)
ordinary user calls admin work

A case of API1 from the official OWASP page is an API that accepts a record ID from the caller but never checks that the ID belongs to that caller. An attacker changes the ID in the request to pull other people's data. OWASP describes an attacker who can list every shop name and scripts requests to pull sales data from thousands of shops. Hard-to-guess IDs such as GUIDs (long random codes) add a layer, but they do not replace the authorization check.

INFOGRAPHIC
A made-up API1 example with no authorization check
01
User A logs in
gets own token
02
Asks for own record
/orders/1001
03
Changes the ID
/orders/1002
04
API skips the check
returns another's data

The other seven risks at a glance

The remaining items are different kinds of problems. The official OWASP page gives examples and defenses for each. In short:

  • API2 Broken Authentication: use established standards instead of home-made code, limit login and password-recovery attempts, ask users to re-authenticate before sensitive actions, add MFA (multi-factor authentication) where possible, and never use an API key (a code that stands in for a program) to authenticate users
  • API4 Unrestricted Resource Consumption: set limits on time, memory, upload size and records per page, use rate limiting (capping requests in a time window), and set spending limits or billing alerts with outside providers. OWASP gives the example of a script that keeps triggering a password-reset SMS until the provider sends tens of thousands of messages in minutes
  • API6 Sensitive business flows: identify the steps that harm the business if called too often, such as buying scarce goods to resell them, then detect non-human behavior such as actions too fast for a person, and harden machine-to-machine APIs
  • API7 SSRF (tricking the server into calling an address the attacker chooses): keep the component that fetches URLs away from the internal network, allow only approved domains, protocols and ports, disable redirects, and never send raw responses back to the user
  • API8 Security Misconfiguration: use a repeatable hardening process, review configuration regularly, encrypt traffic everywhere, restrict the request types accepted, and keep error messages free of internal detail
  • API9 Improper Inventory Management: keep an inventory of hosts, versions and connected services, noting what sensitive data each handles, protect every exposed version with the same controls, and retire or fix old versions
  • API10 Unsafe Consumption of APIs: assess providers' security, encrypt every integration, validate and clean third-party data before use, and never follow redirects without checking them against an approved list of destinations

A practical defense plan

A team can work through these steps in order, starting with the APIs that outside users can reach:

  • Build an API inventory: record hosts, versions, endpoints and the sensitive data each one handles
  • Check authorization on the server for every request: at record, field and function level, and write automated authorization tests
  • Limit resource use: cap request counts, payload sizes and spending with outside providers
  • Validate incoming data: including data from third-party APIs, and limit the destinations the server may fetch
  • Harden and re-check configuration: use a repeatable hardening process and review settings regularly
INFOGRAPHIC
Five steps to defend APIs
1
Inventory APIs
hosts, versions, data
2
Check authorization
record, field, function
3
Limit resource use
requests, size, spend
4
Validate input
including third-party data
5
Harden and re-check
repeatable, regular reviews

An API gateway (a front door for APIs that enforces login, limits request counts and logs requests) and a WAF (a firewall that filters web requests) help with some items, such as limiting request counts. They cannot replace authorization checks in the application code, because only the application knows who owns each record.

When an AI agent or connector tool calls systems on a user's behalf, it usually goes through APIs too, so the authorization problems above can affect that work as well. Read more in What Is MCP? Architecture, Security Risks, and Technical Defenses and Agentic AI Security. For the risks of the web application itself, see OWASP Top 10 for Web Apps.

Common mistakes

  • Believing hard-to-guess IDs mean safe: GUIDs help, but without an authorization check anyone who obtains an ID can fetch the data
  • Checking permissions only in the app screen: an attacker can send requests directly without the screen
  • Leaving old API versions or test hosts online: forgotten ones often lack the protection of the main one
  • Trusting third-party API data more than user data: it must be validated before use as well
  • Setting no spending cap with outside services: for example an SMS service called repeatedly until the bill spikes

Start today

  • Pick the first five externally exposed APIs and inventory them, noting the owner and the data each handles
  • In your own test system, log in as two users and have one try to fetch the other's data; if it works, you have an API1 weakness
  • Check that login, password-recovery and one-time-code endpoints limit the number of attempts
  • Set billing alerts with the outside providers your APIs call
  • Find old API versions and test hosts that are still online, then decide to retire them or protect them like the main one

To see where your organization stands, try the self-assessment.

References and further reading