# API Security: A Complete Guide — Routebase

> 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.

Canonical page: https://routebase.dev/guides/api-security/
Guide overview · 12 chapters · Last reviewed 2026-09-13 · The Routebase Team

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.

_Figure: The first gate asks whether the caller is who they claim to be, and it is the subject of the API authentication guide. The three gates after it ask whether this caller may touch this object, call this function and see this field. The OWASP API Security Top 10 from 2023 puts a category on each of those three, which is why authorization dominates the top of the list._

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](/guides/api-security/broken-object-level-authorization/) |
| API2:2023 Broken Authentication | Can the identity check itself be bypassed, replayed or worn down | [Authentication failures](/guides/api-security/api-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](/guides/api-security/function-and-property-level-authorization/) |
| API4:2023 Unrestricted Resource Consumption | Can one caller exhaust memory, connections, cost or quota | [Resource consumption](/guides/api-security/unrestricted-resource-consumption/) |
| API5:2023 Broken Function Level Authorization | Can an ordinary user call an administrative operation | [Function and property level](/guides/api-security/function-and-property-level-authorization/) |
| 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](/guides/api-security/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](/guides/api-security/server-side-request-forgery/) |
| API8:2023 Security Misconfiguration | Do transport, headers, CORS and leftover endpoints give ground away | [Misconfiguration](/guides/api-security/api-security-misconfiguration/) |
| API9:2023 Improper Inventory Management | What is still answering that nobody has thought about in a year | [Shadow and zombie APIs](/guides/api-security/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](/guides/api-security/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](/guides/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](/guides/api-security/what-a-scanner-cannot-find/) 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](/guides/api-security/broken-object-level-authorization/) | Why the top category is invisible to a single-user test suite |
| [Function and property level authorization](/guides/api-security/function-and-property-level-authorization/) | Admin endpoints without a role check, and fields that leak or over-accept |
| [Authentication failures](/guides/api-security/api-authentication-failures/) | What breaks when the method is right and the validation is not |
| [Unrestricted resource consumption](/guides/api-security/unrestricted-resource-consumption/) | Unbounded pages, oversized bodies and the missing limit |
| [Server side request forgery](/guides/api-security/server-side-request-forgery/) | Why every URL field is an instruction to your server |
| [Misconfiguration, TLS and headers](/guides/api-security/api-security-misconfiguration/) | The settings that give ground away before anyone attacks anything |
| [Shadow and zombie APIs](/guides/api-security/shadow-and-zombie-apis/) | What is still answering that nobody remembers deploying |
| [Running a scan](/guides/api-security/running-an-api-security-scan/) | Target, specification, identities, and what a scan does to the thing it scans |
| [Triaging findings](/guides/api-security/triaging-security-findings/) | Severity against confidence, and the note that ends the argument |
| [Security in CI/CD](/guides/api-security/api-security-in-ci-cd/) | A gate that is still switched on in month three |
| [What a scanner cannot find](/guides/api-security/what-a-scanner-cannot-find/) | Business logic, multi-step abuse and the APIs you consume |
| [Choosing a tool](/guides/api-security/api-security-testing-tools/) | 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](/guides/api-authentication/), and the chapter on security testing inside [API testing](/guides/api-testing/api-security-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.

_Screenshot: The project score, the open findings by severity and a thirty day trend, recalculated from what is still open rather than from what a scan once reported._

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](https://docs.routebase.dev/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.

## Chapters in this guide

1. [Broken Object Level Authorization](https://routebase.dev/guides/api-security/broken-object-level-authorization/): API1:2023 is the flaw a single-user test suite cannot see, why proving it takes two identities from two tenants, and why 404 beats 403 on an object that is not yours.
2. [Function and Property Level Authorization](https://routebase.dev/guides/api-security/function-and-property-level-authorization/): API5:2023 and API3:2023, meaning the admin endpoint that forgot its role check and the response or request body that carries fields this caller has no business with.
3. [Authentication Failures](https://routebase.dev/guides/api-security/api-authentication-failures/): API2:2023 covers what breaks after the method is chosen correctly, from tokens accepted without a valid signature to a login endpoint that answers a thousand guesses.
4. [Unrestricted Resource Consumption](https://routebase.dev/guides/api-security/unrestricted-resource-consumption/): API4:2023 is a design failure rather than an operations problem, covering unbounded pages, oversized bodies, missing limits and the operations that cost money per call.
5. [Server Side Request Forgery](https://routebase.dev/guides/api-security/server-side-request-forgery/): API7:2023 turns any URL field in a request body into an instruction your server carries out, which is why the defence is an allow list rather than a filter.
6. [Misconfiguration, TLS and Headers](https://routebase.dev/guides/api-security/api-security-misconfiguration/): API8:2023 covers the settings that give ground away before anyone attacks anything, from cleartext transport and deprecated TLS versions to a wildcard CORS policy and a live debug endpoint.
7. [Shadow and Zombie APIs](https://routebase.dev/guides/api-security/shadow-and-zombie-apis/): API9:2023 is about what is still answering that nobody remembers deploying, from an old version left running to a staging host with production data behind it.
8. [Running a Scan Against a Live API](https://routebase.dev/guides/api-security/running-an-api-security-scan/): What a scan needs before it starts, what it does to the system it is pointed at, and why concurrency, delay and a time budget are courtesy settings rather than performance settings.
9. [Triaging Findings](https://routebase.dev/guides/api-security/triaging-security-findings/): Severity against confidence, reproducing before reporting, the difference between a false positive and an accepted risk, and what a security score is actually good for.
10. [API Security in CI/CD](https://routebase.dev/guides/api-security/api-security-in-ci-cd/): Where a scan belongs in a pipeline, how to set a gate that is still switched on in month three, and why findings belong in the code host rather than in a second tool.
11. [What a Scanner Cannot Find](https://routebase.dev/guides/api-security/what-a-scanner-cannot-find/): Business logic abuse, multi-step sequences and the APIs you consume are outside automated reach, and knowing where the line runs is what makes a green report mean anything.
12. [What to Look for in an API Security Testing Tool](https://routebase.dev/guides/api-security/api-security-testing-tools/): Eight criteria that decide whether a scanner is still being read in month three, written as questions to put to any tool including the one you already run.

---

[Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.