OWASP API Security Top 10: OWASP API Security Top 10 – Tutorial (about 60 minutes)

The OWASP API Security Top 10 is a free, community-written awareness list of the ten most critical security risks that are specific to application programming interfaces (APIs), the machine-to-machine doors that mobile apps, single-page web apps, partners and internal services use to reach data and business logic. API developers, architects, testers, platform teams, security champions and auditors use it as a shared vocabulary and as a starting point for design reviews and testing. After this tutorial you will be able to explain each of the ten 2023 risks in plain words, recognise them in real requests and designs, place prevention and testing activities across the API lifecycle, and judge what an "OWASP API Top 10" claim from a vendor or a tester really means.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is the OWASP API Security Top 10 2023, published by the OWASP API Security Project of the OWASP Foundation (the Open Worldwide Application Security Project, a non-profit). It is the second edition: the first appeared in 2019, and the 2023 edition was released in early June 2023 after a public release candidate earlier that year. The text is licensed under Creative Commons Attribution-ShareAlike 4.0. As of the verification date OWASP has not announced a newer API edition; recent activity in the project repository is translations and housekeeping, and the 2023 list remains current. It should not be confused with the OWASP Top 10:2025, which covers web applications in general. There is no certification scheme for the API Security Top 10. Verified 2026-10-29 against the official project site (api-security.owasp.org) and its GitHub repository.

Who this is for: back-end and mobile developers, API product owners, solution architects, QA and test engineers, DevOps and platform engineers who run API gateways, junior penetration testers, security champions, and governance or audit staff who meet phrases such as "the API was tested against the OWASP API Top 10" in reports, contracts or tool data sheets.

Prerequisites: none. It helps to know that a client sends an HTTP request (for example GET /orders/42) and a server answers with data, often in JSON, but every security term is explained when it first appears. You do not need to write code to follow the lessons.

By the end of this tutorial:

You will be able to explain why APIs got their own OWASP list, who publishes it, how the 2023 edition was produced and why it is an awareness document rather than a testable standard.
You will be able to name and describe the ten 2023 risks, from API1 Broken Object Level Authorization to API10 Unsafe Consumption of APIs, and say what changed from 2019.
You will be able to tell apart the three authorization risks (object, object property and function level) using concrete requests.
You will be able to choose sensible preventive controls for each risk and say which layer (code, gateway, platform, business process) owns them.
You will be able to place Top 10 activities into each phase of an API lifecycle, from design to retirement, and plan how to test for them.
You will be able to evaluate claims of "OWASP API Top 10 coverage" and pick a verifiable companion standard when requirements are needed.

Lesson 1 – Origins, purpose and scope

Why APIs needed their own list

Ten years ago many applications were server-rendered: the server built a whole HTML page and the browser displayed it. Today most products are built as a set of APIs. A mobile banking app, a single-page web shop, a smart car, a partner integration and a microservice inside a Kubernetes cluster all talk to back ends through APIs. The API is no longer an internal detail; it is the product's real front door.

This shift changes where attacks happen. In a server-rendered page the server decides what to show, so a lot of filtering happens before data leaves the building. With an API, the server often returns raw objects and lets the client decide what to display. Attackers do not use your app; they call your API directly with tools such as a proxy or a script, change identifiers, add fields, replay requests at high speed and look for endpoints the app never shows. Many API data exposures need no clever exploit, only ordinary calls that the server should have refused.

The general OWASP Top 10 for web applications covers some of this, but its categories are broad and were shaped by data from traditional web testing. The OWASP API Security Project was created to give API builders a focused list in their own language: object identifiers, properties, endpoints, rate limits, inventories and integrations.

Who publishes it and how it is made

OWASP is a global non-profit foundation that runs open, volunteer-led projects on software security. Its projects publish their material for free under open licences. The API Security Project is one of them, led by a small team of volunteers with input from the wider community through GitHub and mailing lists.

The first list was published in 2019. The 2023 edition was prepared in phases. The team first collected and classified publicly reported API security incidents, many from bug bounty programmes (schemes where companies pay independent researchers who report flaws) and published write-ups, considering only issues reported between 2019 and 2022. A public call for data ran from September to November 2022, but it did not deliver data that would support a meaningful statistical ranking. In parallel the team discussed what had changed since 2019 and met specialists in API threats. From this it drafted the ten risks and rated them with the OWASP Risk Rating Methodology, with prevalence set by consensus of the team members' field experience. Experienced API security practitioners reviewed the draft, a release candidate was published for community comment in February 2023, and the final version followed in June 2023.

Figure 1 – How the 2023 edition was produced: incident research, a call for data, expert drafting and rating, practitioner review and a public release candidate before the final release.

This history matters when you use the list. The order is an expert judgement about risk, not a measured frequency table. Item 1 is not "the bug found most often in your APIs"; it is the risk the team judged most critical for APIs in general. Your own organisation may see a different order.

What it is and what it is not

The project describes its output as an awareness document. Its job is to make people who build and run APIs aware of the most important classes of risk, explain how attackers exploit them, and point towards prevention. It is short on purpose: one page per risk.

It is not a requirements standard. It does not contain numbered "shall" statements, assurance levels or pass/fail criteria. It is not a full list of everything that can go wrong with an API. It is not a certification scheme. And it does not replace the general web list: the team deliberately left out generic risks, such as injection or vulnerable third-party components, that behave the same way in an API as in any other software. Those risks still apply to your API; they are simply covered elsewhere, mainly in the web Top 10 and in the Application Security Verification Standard (ASVS).

Scope in practice

The list applies to any interface that programs call over a network: REST APIs using JSON over HTTP, GraphQL APIs that accept flexible queries, gRPC and other RPC styles, webhooks, and internal service-to-service APIs. The example scenarios on the official pages mix REST and GraphQL requests, which shows that the risks are about how authorization, resources and trust are handled, not about one protocol.

Lesson 2 – Key concepts and vocabulary

The ten risks use a small set of terms again and again. Learn these first and the rest of the course becomes much easier.

API (application programming interface) – a defined way for one program to ask another for data or actions, usually over HTTP. Its contract lists endpoints, parameters, data formats and responses.
Endpoint – one addressable operation of an API, for example GET /v2/orders/{orderId} or a named GraphQL mutation such as deleteDocument.
Object – a data record that the API exposes, such as an order, an invoice, a vehicle or a user profile. Objects usually have an identifier (ID) that clients send in the path, query string or body.
Object property – a single field of an object, such as email, isAdmin, price or internalNotes. Some properties are fine for everyone to read, some only for the owner, some for nobody outside the company.
Authentication – proving who the caller is, for example by password plus one-time code, an OAuth 2.0 access token or a client certificate. It answers "who are you?".
Authorization – deciding whether this authenticated caller may perform this action on this object or field. It answers "are you allowed to do this?". Most of the 2023 list is about authorization failures.
IDOR (insecure direct object reference) – an older name for the situation in which a client can access someone else's record just by changing an ID. The API list calls this Broken Object Level Authorization (BOLA).
Excessive data exposure – an API returns more properties than the client needs and relies on the front end to hide them. Anyone calling the API directly sees everything.
Mass assignment – an API automatically copies every field from a request body into an internal object, so a caller can set fields they should not control, such as role or balance.
Rate limiting and throttling – rules that cap how many requests a client may send in a time window (rate limiting) or slow repeated sensitive actions down (throttling).
Business flow – a sequence of API calls that together deliver business value, such as search, reserve, pay and confirm a ticket. Abuse of a flow can hurt the business even when every single call is technically valid.
SSRF (server-side request forgery) – tricking a server into making network requests to a destination chosen by the attacker, for example an internal admin service or a cloud metadata address that is not reachable from the internet.
API inventory – an up-to-date record of every API host, version, environment, audience and data flow that an organisation runs, including integrations with third parties.
OpenAPI description – a machine-readable description of a REST API's endpoints, parameters and schemas (formerly called Swagger). It powers documentation, client generation, gateways and tests.
API gateway – a component in front of APIs that handles routing, authentication checks, quotas, rate limits, logging and sometimes schema validation.
Third-party (upstream) API – an external service your API calls, such as a payment provider, an address lookup or a code hosting service. Its responses are input to your system.

Three levels of authorization

The 2023 list separates authorization into three levels, and this idea is the key to the whole document. Think of a hotel. Function level asks whether you may enter the staff-only office at all. Object level asks whether your key card opens room 214 or only your own room 212. Property level asks, once you are inside a room you may enter, which drawers you may open and which items you may change. An API needs checks at all three levels on every request, and a missing check at any one of them is a separate risk in the list.

Threat agent, weakness and impact

Each risk page is written in risk language. A threat agent is whoever might attack (an anonymous user, a customer, a partner, a bot operator). A weakness is the flaw in the API. Impact is the harm: technical (data read, changed or destroyed, service down) and business (fraud, fines, lost trust, higher cloud bills). Keeping these three apart helps you explain findings to non-technical owners.

Lesson 3 – Structure of the list and the ten risks at a glance

How each entry is built

Every risk is identified by a code made of the position and the edition year, such as API1:2023. The year matters: API3:2019 and API3:2023 are different risks, so always include it in tickets and reports.

Each risk has a page with the same parts: a short risk-factor summary (threat agents and attack vectors, security weakness, impacts), a section on how to tell whether an API is vulnerable, several example attack scenarios drawn from real-world patterns, prevention advice, and references to related OWASP resources and, on most pages, CWE entries (CWE, the Common Weakness Enumeration, is MITRE's catalogue of software weakness types).

How the risks are rated

The list uses a simplified form of the OWASP Risk Rating Methodology. For each risk the team rates exploitability (how easy it is to exploit), weakness prevalence (how common it is), weakness detectability (how easy it is to find) and technical impact, each on a three-step scale. Threat agents are marked "API specific" and business impact "business specific", because the project cannot know your attackers or your losses. For example, broken object level authorization is rated easy to exploit, widespread and easy to detect, with moderate technical impact.

The project is open about the limits: the rating ignores the likelihood of a particular threat agent, the details of your application and your real business impact. Each organisation has to decide its own risk appetite. So re-rate every real finding in your own context.

The ten risks

Code	Risk	In one sentence
`API1:2023`	Broken Object Level Authorization	The API accepts an object ID from the client but does not check that this caller may access that specific object.
`API2:2023`	Broken Authentication	Weak or wrongly built login, token or credential-recovery mechanisms let attackers act as other users.
`API3:2023`	Broken Object Property Level Authorization	The API lets callers read or write individual fields they should not, through over-sharing responses or mass assignment.
`API4:2023`	Unrestricted Resource Consumption	Missing limits on request size, frequency, work or paid third-party calls lead to outages or large bills.
`API5:2023`	Broken Function Level Authorization	Ordinary users can call administrative or privileged operations because the role check is missing or wrong.
`API6:2023`	Unrestricted Access to Sensitive Business Flows	A legitimate business flow can be automated at scale (scalping, spam, hoarding) and harms the business.
`API7:2023`	Server Side Request Forgery	The API fetches a URL supplied by the client without validating it, so the server can be steered to internal targets.
`API8:2023`	Security Misconfiguration	Missing hardening, verbose errors, permissive CORS, missing TLS or unnecessary features expose the API stack.
`API9:2023`	Improper Inventory Management	Forgotten versions, hosts, environments and data flows stay exposed because nobody knows they exist.
`API10:2023`	Unsafe Consumption of APIs	The API trusts data and redirects from third-party APIs more than user input and is attacked through them.

Five families

The grouping below is a teaching aid, not part of the official document, but it reflects how the risks relate.

Figure 2 – The ten 2023 risks grouped into five teaching families: authorization, identity, abuse and cost, platform and estate, and trust in third parties.

What changed from 2019

This helps you read older reports and tools that still use 2019 codes.

Two 2019 items, Excessive Data Exposure and Mass Assignment, were merged into the new API3, because they share one root cause: missing authorization checks on individual properties.
Lack of Resources and Rate Limiting was renamed Unrestricted Resource Consumption, shifting the emphasis from "add a rate limit" to "control everything a request can consume", including money spent on paid services.
Broken User Authentication became Broken Authentication; the 2023 page also covers service-to-service authentication, for example microservices that accept calls without authentication.
Improper Assets Management became Improper Inventory Management.
Three items are new in 2023: Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery and Unsafe Consumption of APIs.
Injection and Insufficient Logging and Monitoring no longer appear as their own items. They still matter: the project names injection as a generic risk that behaves the same in APIs as elsewhere, and both topics are covered by the web Top 10 and ASVS.
Broken Object Level Authorization and Broken Function Level Authorization kept their names; Security Misconfiguration moved from position 7 to position 8.

Lesson 4 – Inside the ten risks and how to prevent them

This lesson walks through each risk: what goes wrong, a simple example and the main preventive controls. The official pages have more scenarios.

API1 – Broken Object Level Authorization

Almost every API has endpoints that take an object identifier: /accounts/{id}, /vehicles/{vin}/unlock, a GraphQL query with a document ID. If the server only checks that the caller is logged in, any logged-in user can change the ID and reach someone else's object. Attackers find these flaws easily by swapping IDs between two test accounts. The official example scenarios include reading thousands of online shops' sales figures and remotely unlocking cars that belong to other people.

Figure 3 – A broken object level authorization flaw: the token is valid, but the service never checks that the requested order belongs to the caller.

Prevention starts with design. Define an authorization model based on users, roles, ownership and account hierarchy. Then, in every function that uses a client-supplied identifier to read, change or delete data, check that this caller may act on that record. Put the check in a shared, well-tested component rather than re-writing it per endpoint. Using random, hard-to-guess identifiers such as UUIDs makes enumeration slower, but it is a supporting measure only: IDs leak through logs, links and shared screens, so they must never replace the ownership check. Finally, write automated tests that try to access another user's object and fail the build if they succeed.

API2 – Broken Authentication

Authentication endpoints are attractive because success gives the attacker a whole identity. Common weaknesses include login or one-time-code endpoints without brute-force protection, password reset flows weaker than login, tokens that are not validated properly (for example accepting unsigned JSON Web Tokens or not checking expiry), credentials sent in URLs, and sensitive changes such as email address or phone number updates allowed without re-entering the password. GraphQL batching can also let an attacker try hundreds of passwords inside a single HTTP request, defeating a per-request limit.

Prevention: know every authentication flow you have, including mobile, partner and "forgot password" paths. Use proven standards and libraries rather than home-made schemes. Treat credential recovery as seriously as login. Apply stricter anti-automation (lockout, CAPTCHA, progressive delays) on authentication than on ordinary endpoints. Require re-authentication for sensitive account changes, support multi-factor authentication, validate token signatures, audience and expiry, and use API keys to identify client applications, not to authenticate end users.

API3 – Broken Object Property Level Authorization

Here the caller may access the object but not every field in it. Two shapes are common. In the read direction the API returns the whole database record, including fields like passwordResetToken or a host's full address, and leaves the client to hide them. In the write direction the API binds every field in the request body, so a renter who updates their booking can also send "approved": true or "price": 0.

Prevention: decide explicitly which properties each role may read and write. Never use generic serialisation such as "convert the whole object to JSON"; instead return purpose-built response shapes. Avoid automatic binding of client input to internal objects, or use an allowlist of fields that may be changed. Validate responses against a schema so new internal fields do not leak by accident, and keep returned data to the minimum each use case needs.

API4 – Unrestricted Resource Consumption

Every request consumes something: CPU, memory, storage, bandwidth, database connections, and often money, because many APIs call paid services such as SMS, email, identity verification or AI models. If nothing limits these, an attacker can cause a denial of service (making the service unavailable) or a denial of wallet (making it ruinously expensive). Examples include scripting tens of thousands of password-reset requests that each send a paid text message, or using a single batched GraphQL request to trigger many expensive image resizes.

Prevention combines limits at several layers: cap memory, CPU and processes in containers or serverless settings; set maximum sizes for strings, arrays, uploads and pages of results; limit how often a client may call each endpoint, with tighter limits on expensive or sensitive ones; validate parameters that control how many records are returned on the server; limit query depth and cost for GraphQL; and set spending limits or billing alerts with every third-party provider.

API5 – Broken Function Level Authorization

APIs often mix ordinary and administrative operations, and they are easy to guess: if GET /api/users/me exists, an attacker will try GET /api/admin/users, or change GET to DELETE. Complex role hierarchies, partner versus customer APIs and group memberships make mistakes likely. The difference from API1 is the question asked: API5 is "may this kind of user call this operation at all?", while API1 is "may this user touch this particular record?".

Prevention: deny by default and grant each role explicit access to each function. Centralise authorization in one module that all endpoints use. Make administrative controllers inherit from a base that enforces the admin check. Review every endpoint, including those not used by your own front end, and test that ordinary users receive a refusal for privileged operations and methods.

API6 – Unrestricted Access to Sensitive Business Flows

Sometimes nothing in the code is broken. Every request is authenticated, authorised and well formed, but the business process was never designed for machine speed. Bots buy an entire stock of a new games console on launch day and resell it; a user books most seats on a flight and cancels at the last minute to force a price drop; a script creates fake accounts to collect referral credit. The harm is commercial and reputational, and what counts as "too much" depends on the business.

Prevention starts with the business, not the code. Identify which flows would hurt if used excessively (purchases, reservations, referrals, comments, account creation). Describe normal usage for each, so abuse can be spotted. Then choose engineering controls that raise the attacker's cost: device fingerprinting to reject unexpected clients, human-presence checks such as CAPTCHAs or behavioural signals, detection of non-human timing (checkout in under a second), and blocking known anonymising proxies where appropriate. Remember partner and machine-to-machine APIs, which often expose the same flows with fewer controls.

API7 – Server Side Request Forgery

Features such as "import a profile picture from a URL", webhooks that call a customer-supplied address, link previews and file conversion all make the server fetch a remote resource. If the server accepts any URL, an attacker can point it at internal systems behind the firewall, at cloud instance metadata services that hand out credentials, or at local ports for scanning. Sometimes the response comes back to the attacker; sometimes the attack is "blind" and they infer results from timing.

Prevention: isolate the fetching component on a network segment that cannot reach sensitive internal targets. Use allowlists of permitted destinations, URL schemes, ports and media types. Turn off automatic following of HTTP redirects. Use one well-tested URL parser to avoid parsing tricks, validate and sanitise all client-supplied URLs, and never return raw responses from the fetched resource to the client.

API8 – Security Misconfiguration

An API runs on a stack of components: web server, framework, gateway, container platform, cloud services, identity provider. Each has settings, and defaults are rarely the most secure choice. Typical problems include missing patches, unnecessary HTTP methods enabled, missing TLS on internal hops, cross-origin resource sharing (CORS) that allows any website to call the API with users' credentials, missing security headers or cache controls on sensitive responses, and error messages that reveal stack traces or internal hostnames.

Prevention: use a repeatable hardening process so environments are configured the same way; keep configuration as code and review it; scan configuration and the running stack automatically in the pipeline; encrypt all traffic with TLS; restrict each endpoint to the HTTP methods it needs; set a deliberate CORS policy; define and enforce response formats and content types; and return generic error messages while logging details internally.

API9 – Improper Inventory Management

Organisations move fast and leave things behind: a v1 API still running after v2 launched, a beta host with production data, a debug endpoint, a partner integration nobody remembers approving. Attackers use search engine queries, DNS enumeration and specialised search engines for internet-connected servers to find these forgotten hosts, which often run unpatched code with weaker protections. The project describes two kinds of blind spot: documentation blind spots (unknown environment, audience, version or retirement plan) and data flow blind spots (sensitive data shared with third parties without a recorded justification or approval).

Prevention: inventory every API host with its environment, intended audience and version; inventory integrated services and the data they receive; generate documentation from an open format such as OpenAPI as part of continuous integration and continuous delivery (CI/CD); restrict documentation to those who need it; protect all exposed versions, not only the newest; keep production data out of non-production environments or protect them equally; and when a new version brings security fixes, decide by risk analysis whether to backport them to older versions or retire those versions quickly.

API10 – Unsafe Consumption of APIs

Developers usually validate input from users but often trust data from well-known partners or services. Attackers know this and attack the integration instead: they plant a malicious payload in a third-party record your API later reads and stores, or they compromise the partner and make it redirect your API's request, along with its sensitive payload, to their own server. Interaction over unencrypted channels and blind following of redirects make this worse.

Prevention: assess the security of service providers before integrating; use TLS for all API-to-API traffic; validate and sanitise all data received from integrated APIs exactly as you would user input; keep an allowlist of locations to which your API may be redirected and do not follow redirects blindly; and set timeouts and resource limits on calls to third parties so a slow or hostile partner cannot exhaust your service.

Which layer owns which control

A common mistake is to expect one product to solve everything. A gateway or web application firewall (WAF) is very good at size limits, rate limits, schema checks, TLS and blocking known bad clients, which helps with API4, API8 and parts of API2 and API6. It cannot know who owns order 1001 or which fields a renter may change, so API1, API3 and API5 must be fixed in application code and tested there. API9 is mostly a process and tooling problem, API6 needs business owners, and API10 needs both architecture decisions and code.

Lesson 5 – Using the list across the API lifecycle, testing and assessment

Shift the list left and keep it on the right

The list is most valuable when it is part of everyday work, not only a final penetration test. The diagram shows where each family naturally fits in an API lifecycle.

Figure 4 – Where the risk families fit into the API lifecycle, from design-time threat modelling to inventory and retirement in operation.

Plan and design. Run a threat model for each new API or major change: draw the data flows, list callers and roles, mark sensitive business flows and every third-party integration. Ask the ten questions the list implies.
Specify. Write an OpenAPI or GraphQL schema first. Define request and response shapes per role, maximum sizes, and which roles may call which operations. This contract later drives tests and gateway rules.
Build. Use a shared authorization library or policy engine, purpose-built data transfer objects instead of raw database records, and well-known authentication libraries. Follow the OWASP cheat sheets for REST, GraphQL and authentication.
Test and verify. Add automated tests that use two users and two roles to try cross-access. Run API-aware dynamic scanners and fuzzers against the contract. Commission manual testing for business logic.
Deploy. Publish only through the gateway, with rate limits, quotas, TLS, CORS and logging defined as code.
Operate. Keep the inventory current, discover unknown APIs from traffic and DNS, watch for enumeration patterns and spikes in cost, and review third-party data flows.
Retire. Announce deprecation, monitor remaining usage, then switch old versions off and remove their hosts and DNS records.

Roles

Developers own the code-level authorization and input handling. Architects own the authorization model, integration design and network isolation for features that fetch URLs. Platform teams own gateways, configuration baselines and the inventory tooling. Product and business owners decide which flows are sensitive and what usage is normal. Security teams or champions provide training, threat-modelling support, testing and risk ratings. A short RACI (responsible, accountable, consulted, informed) table for the ten risks avoids gaps.

How to test for the risks

Different risks need different testing techniques, which is why no single tool covers the list.

Authorization (API1, API3, API5) – create at least two users per role and replay each request with the other user's token and IDs, change HTTP methods, add unexpected fields to bodies and compare responses with the intended contract. Automated scanners find some of this when they understand the schema, but business context usually requires a human.
Authentication (API2) – review every login, token and recovery path; check token validation, lockout and re-authentication for sensitive changes.
Consumption and flows (API4, API6) – load and abuse tests in a safe environment, oversized payloads, large page sizes, batched or deeply nested GraphQL queries, and scripted runs of key business flows.
SSRF (API7) – supply internal addresses, alternative URL encodings and redirecting URLs to every parameter that takes a URL.
Configuration and inventory (API8, API9) – configuration scanning, header and CORS checks, comparing gateway logs and DNS records with the official inventory.
Integrations (API10) – design review of each integration plus tests with malicious or malformed upstream responses using mocks.

Assessment, certification and compliance

There is no OWASP certification for the API Security Top 10, no accredited auditors and no "compliant" badge. OWASP does not endorse products or services. When a scanner, gateway or testing firm claims "full OWASP API Top 10 coverage", treat it as marketing until you know exactly which checks were run for each risk and which risks need human judgement. A scan report that shows "0 findings for API1" may simply mean the tool had only one user account and could not test cross-user access.

The list is still widely used in assessments. Penetration test reports, procurement questionnaires and internal policies often use its codes to classify findings or define test scope. Regulations and industry frameworks may require secure development and protection against common attacks, and organisations often cite the list as one of their references. When you need requirements that can be verified, pair the list with the OWASP ASVS, which has testable requirements at three levels, and with a testing guide such as the OWASP Web Security Testing Guide.

A sound assessment approach looks like this: agree the scope (which APIs, versions and environments, based on the inventory); map each Top 10 risk to concrete test cases and ASVS requirements; run automated and manual tests; rate each finding using your own context (likelihood and business impact), not the generic rating; track remediation with the risk code in each ticket; and re-test.

Lesson 6 – Worked example: securing a food delivery platform's APIs

The situation

"FreshRoute" is a fictional mid-sized food delivery company. It has a customer mobile app, a restaurant partner portal (a single-page web app), a courier app and a public partner API used by two large restaurant chains. Everything is built from about 30 microservices behind an API gateway in a public cloud. After a customer reported seeing someone else's order history, the chief technology officer asks the platform team to review the APIs against the OWASP API Security Top 10 within one quarter.

Step 1 – Build the inventory first

The team cannot test what it does not know. It exports routes from the gateway, lists DNS names and TLS certificates, and asks each squad for its services. The comparison finds three surprises: an old v1 customer API still reachable at a legacy hostname, a beta host running the latest code with a copy of real customer data, and an undocumented data feed that sends customers' phone numbers to a marketing analytics vendor. All three are API9 findings. The team records each API's owner, environment, audience, version and data flows, generates documentation from OpenAPI files in the pipeline, removes the beta host's real data and schedules the v1 shutdown after notifying the two partner chains.

Step 2 – Threat model the important flows

In short workshops with product owners the team draws the main flows: sign-up, login, browse, order, pay, apply promotion, rate a courier, and partner menu updates. Product owners mark two sensitive business flows: new-customer promotion codes (worth real money) and "reserve a delivery slot" during peak hours. The workshop also lists integrations: a payment provider, an address-validation service, an SMS provider, and a menu-import feature that lets restaurants paste a URL of their menu file.

Step 3 – Test and find

Using two customer accounts, two restaurant accounts and one courier account, testers replay requests across users and roles. Findings, each tagged with its risk code:

Finding	Risk	Fix chosen
Order history endpoint returns any customer's orders when the customer ID in the path is changed	`API1:2023`	Derive the customer from the token, ignore the path ID for customers, add ownership checks in a shared policy module and cross-user tests in CI
Courier profile response includes home address and bank details used only by finance	`API3:2023`	Role-specific response objects and response schema validation
Restaurant "update menu item" accepts a `commissionRate` field	`API3:2023`	Allowlist of writable fields per role
Partner API exposes `POST /admin/refunds` to any partner key	`API5:2023`	Deny-by-default role mapping in the gateway and service
One-time login code endpoint allows unlimited guesses; the SMS resend endpoint has no limit	`API2:2023`, `API4:2023`	Attempt limits and lockout, resend throttling, SMS spending cap and alert
Scripts create thousands of new accounts to reuse first-order promotions	`API6:2023`	Device and payment-instrument signals, promotion limits per verified phone, anomaly alerts
Menu-import URL can point to the cloud metadata address	`API7:2023`	Fetch from an isolated worker with an allowlist of schemes and ports, no redirects
Errors return stack traces; CORS allows any origin with credentials	`API8:2023`	Generic errors, strict CORS list, hardening baseline in configuration code
Address-validation responses are stored without validation and follow redirects	`API10:2023`	Validate and sanitise responses, TLS only, redirect allowlist, timeouts

Step 4 – Prioritise with context

The team does not fix in list order. It rates each finding with the OWASP Risk Rating Methodology using its own facts. The order-history flaw is easy to exploit, affects all customers and already caused a complaint, so it is fixed and deployed within days, and logs are reviewed to see whether anyone scraped data. The SSRF finding is next, because cloud credentials could lead to full compromise. The promotion abuse costs money every week, so product and engineering share that work. Configuration items are bundled into the hardening baseline.

Figure 5 – FreshRoute's simple triage path: findings are prioritised by real business context, then every fix gets a regression test and a re-test.

Step 5 – Make it stick

Fixing findings once is not enough; the same classes return with the next feature. FreshRoute adds a short API security checklist based on the ten risks to its design template, runs cross-user authorization tests in every pipeline, adds gateway policies for size and rate limits as code, and makes the inventory a required step before any new hostname gets a certificate. It maps its checks to ASVS requirements so the next external test has a clear, verifiable scope. Six months later, a re-test finds two new property-level issues in a new loyalty feature, caught before release by the pipeline tests. The programme is working: not because FreshRoute is "certified", but because the list shaped its habits.

Lesson 7 – Relationship to other standards and frameworks

The API Security Top 10 is one piece of a larger set of resources. Use it for awareness and prioritisation, and use its neighbours for requirements, testing methods and architecture guidance.

Resource	Owner	What it is	How it relates to the API Top 10
OWASP Top 10:2025	OWASP Foundation	Awareness list of the ten most critical web application risk categories	Covers general risks (injection, supply chain, cryptographic failures) that the API list deliberately leaves out; use both for any API-based product
OWASP ASVS 5.0	OWASP Foundation	Application Security Verification Standard: testable security requirements at three levels	Turns awareness into verifiable requirements, including chapters relevant to APIs, authorization and authentication; the natural basis for contracts and test scopes
OWASP Web Security Testing Guide	OWASP Foundation	Detailed testing methodology for web applications and services	Explains how to test for many weaknesses behind the API risks, such as authorization bypass and SSRF
OWASP Mobile Top 10	OWASP Foundation	Awareness list for mobile app risks	Mobile apps depend on back-end APIs; teams building a mobile product should read both lists
NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems	US National Institute of Standards and Technology	Guidance on API risks and recommended controls before and during runtime (June 2025, updated March 2026)	Gives architecture-level controls (gateways, schemas, keys, inventories) that implement many of the preventions the Top 10 recommends
CWE	MITRE	Catalogue of software and hardware weakness types	Most API risk pages reference CWE entries; use them for precise classification in tools and tickets

A practical way to combine them: use the API Top 10 to train teams and structure threat models, the ASVS to state requirements and acceptance criteria, the testing guide and cheat sheets to build tests and code, NIST SP 800-228 to shape your gateway and runtime architecture, and CWE codes to label findings consistently. If your API serves AI features, the OWASP Top 10 for Large Language Model Applications adds AI-specific risks, but the API risks still apply to the endpoints that expose those features.

Notice how the documents differ in kind. The two Top 10 lists and the Mobile Top 10 are awareness documents. ASVS is a verification standard. The testing guide is a method. NIST SP 800-228 is a guideline from a government agency. None of them is a certification scheme on its own, although organisations and regulators may refer to them.

Common pitfalls and best practices

Pitfalls

Treating the list as a complete checklist and declaring an API "secure" after checking ten boxes, ignoring injection, vulnerable dependencies and other general risks.
Relying on authentication alone: a valid token proves identity, not permission to touch a specific object, field or function.
Expecting a gateway, WAF or scanner to find or block authorization flaws that only the application can judge.
Using hard-to-guess IDs or hiding fields in the user interface as the main defence instead of real server-side checks.
Protecting only the newest API version while old versions, beta hosts and partner endpoints stay exposed.
Trusting partner and third-party API responses as if they were safe internal data.
Mixing up 2019 and 2023 codes in reports, so that "API3" means different things to different readers.
Fixing findings in list order instead of by real risk to your own business.

Best practices

Start with an inventory of hosts, versions, audiences and data flows, and keep it current automatically.
Define an explicit authorization model covering function, object and property level, and enforce it in one shared, tested component.
Design contract-first with OpenAPI or GraphQL schemas, purpose-built response shapes and allowlists for writable fields.
Add automated cross-user and cross-role tests to every pipeline and fail the build when they fail.
Set limits for size, rate, query cost and third-party spending, and involve product owners in protecting sensitive flows.
Use the list for awareness and structure, and ASVS for verifiable requirements and test scope.
Always write risk codes with the year, for example API1:2023.
Re-rate each finding with your own threat agents and business impact before deciding priority.

Summary and key takeaways

The OWASP API Security Top 10 2023 is the current edition of OWASP's free awareness list of API-specific risks; it followed the 2019 edition, and no newer edition had been announced as of October 2026.
It was produced from incident research and expert consensus with community review, so the order is a judgement of risk, not a frequency count.
Three of the ten risks are authorization failures at different levels: object (API1), object property (API3) and function (API5).
Other risks cover authentication (API2), abuse of resources and business flows (API4, API6), the platform and estate (API7, API8, API9) and trust in third-party APIs (API10).
Generic risks such as injection were left out on purpose; use the web Top 10 and ASVS alongside this list.
Controls live in different layers: application code for authorization, the gateway and platform for limits and configuration, process for inventory, and business owners for sensitive flows.
There is no certification; treat "full coverage" claims critically and use ASVS when you need testable requirements.
Lasting improvement comes from building the risks into design, pipelines, inventory and retirement, not from a single test.

Reflection questions

Pick one API you know. For three of its endpoints, write down how the server checks function level, object level and property level authorization. Where is each check implemented, and how is it tested?
How would you find every API host and version your organisation exposes today, including partner and beta environments? Who would own keeping that list current?
Which business flow in your product would cause the most harm if a bot ran it a thousand times faster than a human? What would normal usage look like, and how would you notice abuse?
A vendor says its tool "covers all of the OWASP API Top 10". Which questions would you ask to understand what it really tests, and which risks would you still test manually?
List the third-party APIs your system calls. For each, how is incoming data validated, are redirects followed, and what happens if the provider is compromised or very slow?