API security essentials: the OWASP API Security Top 10 in practice

Why APIs need their own security thinking

Almost every modern application is built on APIs. Mobile apps, single-page web apps, partner integrations and internal microservices all talk to back ends through them. That makes APIs a direct route to business data and business logic, often with far less in the way than a traditional web page.

Two authoritative references are worth knowing. The OWASP API Security Top 10, last updated in 2023, lists the most critical risks specific to APIs. In June 2025, NIST published SP 800-228, Guidelines for API Protection for Cloud-Native Systems, which identifies risks during API development and at runtime, recommends basic and advanced controls across the API lifecycle, and compares ways of implementing them.

This guide works through the OWASP list and turns it into practical controls.

The OWASP API Security Top 10 (2023) at a glance

ID	Risk	In plain terms
API1	Broken Object Level Authorization	A user can reach another user’s records by changing an ID
API2	Broken Authentication	Weak login or token handling lets attackers impersonate users
API3	Broken Object Property Level Authorization	Responses expose, or requests modify, fields the user should not touch
API4	Unrestricted Resource Consumption	Requests exhaust compute, storage, bandwidth or paid services
API5	Broken Function Level Authorization	Ordinary users can call administrative functions
API6	Unrestricted Access to Sensitive Business Flows	Legitimate flows are automated and abused at scale
API7	Server Side Request Forgery	The API fetches a URL supplied by an attacker
API8	Security Misconfiguration	Insecure defaults or settings across the stack
API9	Improper Inventory Management	Old, undocumented or debug endpoints remain exposed
API10	Unsafe Consumption of APIs	Data from third-party APIs is trusted without validation

Three of the ten are about authorisation, which is why it gets the most attention below.

Authorisation on every object, property and function

Object level (API1)

Broken object level authorisation happens when an endpoint accepts an identifier, such as /invoices/1042, and returns the record without checking that the caller is allowed to see it. OWASP’s API1 guidance recommends:

An authorisation mechanism based on user policies and hierarchy.
An access check in every function that uses client-supplied input to read or change a record.
Random, unpredictable values (such as GUIDs) for record IDs, as an extra layer rather than a substitute for checks.
Tests that evaluate the authorisation logic, with changes that break those tests not deployed.

In practice, centralise the check: load records through a data-access layer that always scopes queries to what the current user may see, rather than relying on each developer to remember.

Property level (API3)

The 2023 list merged two 2019 categories, excessive data exposure and mass assignment, into one. The fixes are the same discipline applied to fields:

Return only the properties the endpoint needs; avoid serialising whole database objects.
Do not automatically bind request bodies to internal objects. Use explicit allow-lists of fields the client may change.
Validate responses against a schema as an extra safeguard, and keep payloads as small as the use case allows.

Function level (API5)

Administrative and privileged operations need their own checks, denied by default. Do not rely on the client hiding a button or on an obscure URL. Keep administrative APIs separate where possible, and test role boundaries explicitly.

Authentication and tokens (API2)

Most APIs use OAuth 2.0 and tokens. The IETF’s Best Current Practice for OAuth 2.0 Security (RFC 9700, BCP 240, published in 2025) sets out the current baseline. Key points:

Use the authorisation code flow with PKCE. Public clients such as mobile and browser apps must use PKCE, and should use the S256 challenge method.
Do not use the implicit grant, which returns access tokens in the authorisation response, except where the specific risks are mitigated.
Never use the resource owner password credentials grant, because it exposes the user’s credentials to the client.
Match redirect URIs exactly, with a narrow exception for port numbers on localhost redirects used by native apps.
Restrict token audience, so each access token is accepted only by the resource server it was issued for.
Sender-constrain tokens where possible, using mutual TLS or DPoP, so a stolen token is harder to replay.
Protect refresh tokens for public clients by sender-constraining them or rotating them on use.

Beyond tokens: rate-limit and monitor login, password reset and one-time-code endpoints, validate every token’s signature, expiry and audience on every request, and avoid building your own authentication when a mature identity provider will do.

Limit consumption and protect business flows

Resource limits (API4)

An API that does not limit what each caller can consume is open to denial of service and runaway costs. OWASP’s API4 guidance includes:

Cap memory, CPU and processes at the platform level, for example through container or serverless limits.
Set maximum sizes for payloads, strings, arrays and uploaded files.
Rate-limit clients over time, with stricter limits on sensitive operations.
Limit how often a single user can perform operations such as checking a one-time code or requesting password recovery.
Validate parameters that control how many records are returned.
Set spending limits, or at least billing alerts, on third-party services the API calls.

The last point is easy to miss. An API that sends SMS or calls a paid AI or mapping service can be abused to run up a large bill without any data being stolen.

Business flows (API6)

Some abuse needs no bug at all: bulk-buying limited stock, mass-creating accounts, or scraping prices. Identify the flows that would hurt the business if automated, and add controls appropriate to each, such as device or behavioural signals, per-account limits, or human verification at the right step.

Know every API you run (API9)

You cannot protect an endpoint you have forgotten. OWASP’s API9 guidance recommends:

An inventory of API hosts, recording environment, intended audience and version.
An inventory of integrated services and the data that flows to and from them.
Documentation of authentication, errors, rate limits, CORS policy and every endpoint, generated automatically from open standards as part of the CI/CD pipeline.
Protection for every exposed version, not only the current one, and a plan to retire old versions.
No production data in non-production environments, or the same controls if that cannot be avoided.

An OpenAPI description kept in the repository and validated in the pipeline is a practical way to meet several of these at once.

Outbound calls and third-party data (API7 and API10)

When an API fetches a URL supplied by a user, for a webhook, an image import or a link preview, it can be tricked into reaching internal services. That is server-side request forgery. Allow-list destinations and schemes, block internal and metadata address ranges, disable redirects where possible, and run fetchers with minimal network access.

Treat data from partner and third-party APIs as untrusted input too. Validate and sanitise it, use encrypted connections, set timeouts, and do not follow redirects blindly.

Configuration and transport (API8)

Misconfiguration is a broad category. Baseline controls include TLS for all traffic, a restrictive CORS policy, error responses that do not leak stack traces or internal details, security patches applied promptly across the stack, unnecessary HTTP methods disabled, and consistent hardening through infrastructure-as-code rather than manual changes.

Build security into delivery

NIST SP 800-228 separates controls applied before runtime from those applied at runtime, and that is a useful way to organise the work:

Before runtime: threat-model new endpoints, keep an API specification, write automated authorisation tests (including “user A cannot read user B’s data”), and scan dependencies and configuration in the pipeline.
At runtime: enforce authentication, rate limits and payload limits at a gateway or service mesh, log authorisation failures and unusual patterns, and alert on them.

A short API security checklist

Every endpoint authenticates the caller and checks access to each object, property and function.
OAuth flows follow RFC 9700: authorisation code with PKCE, exact redirect matching, audience-restricted tokens.
Payload sizes, rates and expensive operations are limited.
Sensitive business flows have abuse controls.
There is a current inventory and specification of every API and version.
Outbound requests and third-party data are validated.
Configuration is hardened and managed as code.
Authorisation tests run on every build, and runtime logs feed alerts.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.