Home / Knowledge hub / OWASP API Security Top 10
Knowledge hub
OWASP API Security Top 10
The OWASP list of the most serious risks specific to APIs.
What it means
The OWASP API Security Top 10 is a community-written list of the ten most serious risks specific to APIs. It is maintained by OWASP, the Open Worldwide Application Security Project, and is aimed at the people who design, build and test APIs.
It exists because APIs fail differently from web pages. They expose objects and functions directly, they are called by software at scale, and they often have no screen to hide behind. The 2023 edition leads with broken object-level authorisation and broken authentication.
Why it matters
It gives your team and your buyers a shared vocabulary. Security questionnaires, pentest reports and procurement checklists increasingly refer to it, so being able to say which entries you have tested and how is quicker than describing your approach from scratch.
It also tells you where to spend effort. Several of the ten are about access control and business flows, which tools that only look for known vulnerabilities struggle to find. A list does not secure anything, but it stops you testing only the comfortable items.
How it shows up
The 2023 entries are: broken object-level authorisation, broken authentication, broken object property level authorisation, unrestricted resource consumption, broken function-level authorisation, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs. Half of them concern who may do what, and the rest concern limits, exposure and trust in other services.
Use it as a checklist for review, not a certificate. For each entry ask where it could occur in your API, how you would notice, and who has tested it. Many map to pages in this hub: BOLA, broken authentication, resource consumption, SSRF.
Questions people ask
OWASP API Security Top 10, answered
How is it different from the OWASP Top 10?
The OWASP Top 10 covers web applications in general. The API list focuses on risks that are specific to APIs, such as object-level authorisation and inventory of endpoints.
The two overlap, and a product with both a website and an API should look at both.
When was it last updated?
The current edition is 2023. The first was published in 2019.
Check the OWASP project page for the latest version before quoting it in a report or questionnaire, and say which edition you mean.
Does passing a scan mean we cover the list?
No. Automated scans do well on some entries, such as misconfiguration, and poorly on others, such as authorisation and business flows.
Covering the list means testing each entry against how your API actually works.
Is it a compliance standard?
No. It is an awareness document, not a regulation or certification. But auditors, buyers and regulators often use it as a reference for what good testing includes.
You can state which entries you test, and show evidence.
Which entry is most common?
OWASP ranks broken object-level authorisation first. It is easy to introduce, because every endpoint that takes an identifier needs its own check.
Authentication and function-level authorisation follow close behind in the list.
Sources
Where this comes from
Related
Terms that sit next to this one
OWASP Top 10
A widely used list of the ten most critical web application risks.
BOLA
An API returns a record just because you asked for it by number.
Broken authentication
Flaws in sign-in or token handling that let someone pose as another account.
Unrestricted resource consumption
API calls that can use unlimited CPU, memory, money or third-party credits.
API penetration testing
A pentest aimed at your API's endpoints, auth, data access and business rules.
Which of the ten apply to you?
We test web apps and their APIs, including the access-control and business-logic entries that scanners miss. Every finding is something we exploited, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.