API security: common flaws and how to avoid them

API security means protecting the interfaces that applications use to exchange data from unauthorised access, abuse and overload. The flaws that hurt most are rarely exotic: an API that never checks whether this user may read this particular record, an API without limits, or a forgotten old version still answering requests.

Quick Overview

What you will learn:

• Which API flaws OWASP currently ranks highest
• How an object-level authorization attack works and how to block it
• What secure OAuth 2.0 looks like under current IETF best practice
• What the latest update to NIST’s API protection guidance added

Who this article is for:

• Backend developers and architects
• Security testers and penetration testers
• DevSecOps teams running API gateways

Reading time: 7 minutes

Why APIs are a risk category of their own

A web application shows the user a finished screen; an API exposes raw operations on data. That is why OWASP keeps a separate risk list for APIs. The current edition on owasp.org dates from 2023 and replaced the 2019 list. It is an awareness ranking rather than a full standard, but it reflects where teams most often go wrong.

Many entries share one root cause: the server trusts whatever the client sends. A client can submit any object ID, any field in the request body and any number of requests per second. Each of those assumptions has to be checked on the server side.

The flaws that show up most often

These entries from the list on owasp.org come up again and again when business APIs are tested:

• API1:2023 Broken Object Level Authorization (BOLA) — the API accepts an object ID from the client without checking that this user may access that specific object. OWASP recommends object-level authorization checks in every function that reaches a data source using an ID from the user.
• API2:2023 Broken Authentication — flawed authentication lets attackers steal tokens or assume other users’ identities.
• API3:2023 Broken Object Property Level Authorization — the API returns, or lets clients modify, properties they should never see, such as an admin flag.
• API4:2023 Unrestricted Resource Consumption — no limits on requests, payload sizes or costly operations (SMS sending, biometric checks) leads to denial of service or a growing bill.
• API9:2023 Improper Inventory Management — old versions and test environments keep running without current protections.

A basic BOLA check is simple: as a logged-in user, fetch your own resource with curl -H "Authorization: Bearer $TOKEN" https://api.example.com/v1/invoices/1043, then swap in someone else’s ID. If data comes back, the flaw is real.

How to avoid them

• Object-level access control — the access decision is made on the server for a specific record and a specific user, not only per endpoint.
• Schema validation — requests and responses are checked against an OpenAPI or JSON Schema contract that rejects unknown fields (additionalProperties: false), which blocks mass assignment and over-sharing.
• Rate limiting — per-client and per-operation limits at the gateway, a 429 Too Many Requests response with a Retry-After header, and tighter limits on expensive calls.
• API inventory — a register of every version, environment and host, each with an owner and a retirement date.

NIST SP 800-228, “Guidelines for API Protection for Cloud-Native Systems”, on csrc.nist.gov organises these controls along the API lifecycle, separating pre-runtime from runtime and basic from advanced measures. An update dated 13 March 2026 superseded the June 2025 release and added Appendix D, listing API risks by category, and Appendix E, listing recommended controls by lifecycle stage. Use the updated version.

OAuth 2.0 without the old habits

Many APIs are protected by OAuth 2.0 tokens. RFC 9700 on datatracker.ietf.org, the OAuth 2.0 Security Best Current Practice published in January 2025, retires several older patterns:

• clients should not use the implicit grant unless token injection and leakage risks are mitigated;
• the resource owner password credentials grant must not be used;
• public clients must use PKCE;
• access tokens should be audience-restricted, and refresh tokens for public clients must be sender-constrained or rotated.

PKCE itself is defined in RFC 7636 on www.rfc-editor.org: the client creates a one-time secret (the code verifier), sends a derived code challenge with the authorization request and proves possession of the verifier when redeeming the code, so an intercepted authorization code is useless on its own.

Read Also

• Web application security: OWASP in practice — the list for web applications
• API testing: tools and best practices — where security tests fit in
• Red teaming vs penetration testing — choosing the right kind of test

Build Your Skills

Two trainings go deeper: API Security — Protection and Access Control and Open Authentication (OAuth) — Implementation of Secure Authentication. The first covers API threat models and protection strategies, the second OAuth 2.0 implementation and token management. Get in touch to tailor the scope to your team.

Frequently Asked Questions (FAQ)

What is the OWASP risk list, and how is the API edition different?

OWASP’s best-known list ranks the top security risks for web applications. For programming interfaces, OWASP maintains a separate API Security list on owasp.org, currently in its 2023 edition. It puts more weight on object and property authorization, resource consumption and keeping an inventory of interfaces.

How do you run a penetration test on a REST API?

Start from documentation and inventory: the OpenAPI specification, versions and environments. Then test authentication, swapping object IDs between accounts, sending unexpected fields, request limits and access to admin functions with an ordinary token. Map the findings to the API risk list published on owasp.org.

How does API security differ from web application security?

A web application enforces part of its logic in the user interface, whereas an API exposes operations directly, so every check has to live on the server. Tokens, per-object authorization, limits and version management matter more for APIs. Many principles, such as input validation, are shared.

How can a team test API security day to day?

Add negative cases to the automated test suite: requesting someone else’s object, calling without a token, sending an unknown field and exceeding a limit. Run them in the CI pipeline whenever the contract changes. Functional API testing tools handle this well, provided the team deliberately writes abuse scenarios.