API Security: A Complete Guide
API security from the OWASP API Security Top 10 in 2023 through scanning a live API, triaging what comes back, gating a pipeline, and the limits of automation.
Most serious API flaws are not a broken login. They are requests that carried a valid token, passed every check the service performs, and should still have been refused.
That is the ground this guide covers. Authentication asks who is calling, and everything after that asks what this particular caller may do with this particular object, function and field.
Authentication is one question, authorization is three
An API request passes through a sequence of decisions, and only the first one is about identity.
A service can get the first gate exactly right and still hand a customer record to the wrong customer. That is not a rare edge case, because the identity check is centralised in a middleware while the object check lives in every handler that reads an object.
The map, with its identifiers
The OWASP API Security Top 10 is maintained by the Open Worldwide Application Security Project, and the current edition is from 2023. Each category has an identifier, and those identifiers are what scanners, reports and advisories speak in.
| Category | The question it asks | Chapter |
|---|---|---|
| API1:2023 Broken Object Level Authorization | Can one caller reach another caller's object by changing an identifier | Object level |
| API2:2023 Broken Authentication | Can the identity check itself be bypassed, replayed or worn down | Authentication failures |
| API3:2023 Broken Object Property Level Authorization | Does a response carry fields this caller should not see, or accept fields they should not set | Function and property level |
| API4:2023 Unrestricted Resource Consumption | Can one caller exhaust memory, connections, cost or quota | Resource consumption |
| API5:2023 Broken Function Level Authorization | Can an ordinary user call an administrative operation | Function and property level |
| API6:2023 Unrestricted Access to Sensitive Business Flows | Can a flow be automated at a scale the business never intended | What a scanner cannot find |
| API7:2023 Server Side Request Forgery | Can a URL in a request make your server fetch something internal | Server side request forgery |
| API8:2023 Security Misconfiguration | Do transport, headers, CORS and leftover endpoints give ground away | Misconfiguration |
| API9:2023 Improper Inventory Management | What is still answering that nobody has thought about in a year | Shadow and zombie APIs |
| API10:2023 Unsafe Consumption of APIs | Does your service trust the APIs it calls more than it should | What a scanner cannot find |
Three of the ten are authorization failures, and they occupy first, third and fifth place. If you only have budget for one part of this guide, spend it on those three.
Where this guide starts and stops
Three neighbouring subjects have their own homes, so this guide links to them instead of repeating them.
Identity is the authentication guide. Choosing between bearer tokens, API keys, OAuth 2.0 and mutual TLS, and wiring the chosen one up correctly, is covered in API authentication. This guide starts at the point where the token is valid.
A penetration test is people. A scanner runs the same probes against every endpoint on every push, and a tester brings a model of what your business is for. The two are complements rather than substitutes, and the limits chapter is specific about which side of the line each category falls on.
A web application firewall is not a fix. Filtering at the edge buys time against known payload shapes, and it cannot decide whether this caller owns this order. Several categories in the list above are invisible to a firewall by construction, because every request in the attack is well formed and correctly authenticated.
The short answer
If you take one working method from this guide, take this one. Hold two identities from different tenants, cross them against every endpoint that reads or writes an object, and make the result a build step rather than an afternoon someone volunteers for.
Everything else here is that method extended over the other categories, plus the honest account of what it still misses.
| Chapter | Answers |
|---|---|
| Broken object level authorization | Why the top category is invisible to a single-user test suite |
| Function and property level authorization | Admin endpoints without a role check, and fields that leak or over-accept |
| Authentication failures | What breaks when the method is right and the validation is not |
| Unrestricted resource consumption | Unbounded pages, oversized bodies and the missing limit |
| Server side request forgery | Why every URL field is an instruction to your server |
| Misconfiguration, TLS and headers | The settings that give ground away before anyone attacks anything |
| Shadow and zombie APIs | What is still answering that nobody remembers deploying |
| Running a scan | Target, specification, identities, and what a scan does to the thing it scans |
| Triaging findings | Severity against confidence, and the note that ends the argument |
| Security in CI/CD | A gate that is still switched on in month three |
| What a scanner cannot find | Business logic, multi-step abuse and the APIs you consume |
| Choosing a tool | The criteria that separate a scanner from a report generator |
Two neighbouring guides carry part of this ground. The identity half is in API authentication, and the chapter on security testing inside API testing is the short version of what you are reading now.
In Routebase
Routebase includes a scanner that tests running APIs against the OWASP API Security Top 10 from 2023. It reads your specification first, so it sends targeted probes at documented endpoints, parameters and request bodies rather than crawling for links that an API does not have.
The security area is a Pro plan feature, and every In Routebase section in this guide assumes it. Reading the dashboard, runs and findings needs the security:read permission that members already have, while editing profiles, triaging findings and starting scans need security:write and security:execute, which admins and owners have.
The work splits into five pages. Scan profiles hold the configuration, scan runs hold the history, findings are the triage list, personas are the identities the authorization scanners act as, and the dashboard aggregates all of it into a score. Start with Security Overview in the product documentation, or read on.
Frequently asked questions
What is API security?
API security is the work of making sure an interface only does what it was meant to do, for the callers it was meant to serve. It sits one layer past authentication, because most serious API flaws are found in requests that were correctly authenticated and should still have been refused. The standard map of that ground is the OWASP API Security Top 10, whose 2023 edition puts three authorization failures in its top five.
What is the OWASP API Security Top 10?
It is a list of the ten risk categories that appear most often in real API incidents, published by the Open Worldwide Application Security Project and last revised in 2023. Each category has an identifier such as API1:2023, and the identifiers are what security tools and reports refer to. Treat the list as a map of where to look rather than a checklist to tick off, because two APIs with the same ten boxes ticked can be in very different shape.
How is API security different from web application security?
A web application ships a user interface that limits what a caller can ask for, and an API ships the requests themselves. That removes the browser as a constraint, so the attacker works with the same primitives your own client does. It also means the classic scanner technique of crawling links finds almost nothing, because an API surface is described in a specification rather than linked from a page.
Can an API security scanner replace a penetration test?
No, because the two find different classes of problem. A scanner finds the mechanical categories on every endpoint on every run, which covers missing authorization checks, weak input handling and misconfiguration. A penetration test finds the flaws that need a model of your business, such as a sequence of legitimate calls that adds up to something you never intended. Running a scanner continuously is what makes the human time worth paying for.
Last reviewed by The Routebase Team.