API Security
Table of Contents
Quick Answer
API security means making sure every request to an API is authenticated, authorized for the exact record and action it names, limited in what it can consume, and validated before it is trusted. APIs fail differently from web pages because there is no interface to hide behind: clients call endpoints directly. The OWASP API Security Top 10 (2023) is the standard map of what goes wrong, and three of its ten risks, including the first, are authorization failures.
What is API Security?
An API (application programming interface) is how software talks to software: a mobile app to its backend, one service to another, a partner system to yours. API security is the discipline of keeping those conversations safe. It covers who may call an endpoint, what they may do with it, how much they may ask for, and how far the API trusts the data it receives, including data from other APIs.
Most modern applications are APIs with a screen attached. The website and the mobile app are both just clients, and anything they can ask the backend for, anyone else can ask for too.
Why APIs Fail Differently From Web Pages
| On a web page | On an API |
|---|---|
| The interface decides which buttons and fields a user sees. | There is no interface. A caller can send any endpoint, method, identifier or field. |
| Object identifiers are often hidden behind navigation. | Identifiers sit in the request, in plain sight, ready to be changed. |
| A person clicks at human speed. | A script calls thousands of times a minute. |
| The server renders only what it means to show. | The server often returns a whole object and trusts the client to display part of it. |
The consequence is that client-side controls count for nothing. Every decision that matters has to be made again on the server, for every request.
The OWASP API Security Top 10 at a Glance
The OWASP API Security Project publishes the ten most critical API risks. The current edition is 2023. Each risk is explained in full, with prevention steps, in our OWASP API Security Top 10 guide.
| Risk | In plain terms |
|---|---|
| API1 Broken Object Level Authorization (BOLA) | The API checks that you are logged in, but not that the record you asked for is yours. |
| API2 Broken Authentication | Weaknesses in how the API proves who is calling: tokens, passwords, keys and the flows around them. |
| API3 Broken Object Property Level Authorization (BOPLA) | You may access the record, but not every field in it, and the API does not tell the difference. |
| API4 Unrestricted Resource Consumption | No limits on how much work, data or money a single caller can make the API spend. |
| API5 Broken Function Level Authorization (BFLA) | An ordinary user can call an operation that was meant only for administrators or another role. |
| API6 Unrestricted Access to Sensitive Business Flows | The API works exactly as designed, and automation turns that design against the business. |
| API7 Server Side Request Forgery (SSRF) | The API fetches a URL the caller supplied, and can be pointed at systems the caller could never reach directly. |
| API8 Security Misconfiguration | The code may be sound, but the way it is deployed and configured leaves a door open. |
| API9 Improper Inventory Management | You cannot protect an endpoint, version or environment you have forgotten exists. |
| API10 Unsafe Consumption of APIs | Your API trusts the third-party APIs it calls more than it trusts its own users. |
BOLA vs BFLA vs BOPLA: The Three Authorization Risks
Three of the ten risks are about authorization, and they are confused constantly because the names are so alike. They ask three different questions about the same request.
| BOLA (API1) | BFLA (API5) | BOPLA (API3) | |
|---|---|---|---|
| The question | May you touch this record? | May you perform this operation? | May you see or change this field? |
| What goes wrong | You read or edit another user's data. | You call a function meant for another role. | You receive hidden fields, or set fields you should not control. |
| Typical sign | Changing an ID in the request works. | Changing the method or path works. | Extra fields in a response, or an extra field in a request is accepted. |
| The fix lives in | A per-object ownership check. | A deny-by-default role policy per function. | Explicit response objects and writable-field allowlists. |
Authentication answers "who are you?" once. Authorization has to answer all three of these on every request, which is why it is where most API breaches begin. Our guide to Broken Object Level Authorization covers the first in depth.
API Security Best Practices
| Area | What good looks like |
|---|---|
| Design | Write the API specification first, and decide who may call each operation before any code exists. |
| Authentication | Use a standard, maintained framework. Validate every token fully: signature, algorithm, issuer, audience, expiry. |
| Authorization | Deny by default. Check the object, the function and the fields on every request, on the server. |
| Input and output | Validate requests against a schema. Return explicit response objects, never the raw database entity. |
| Limits | Rate-limit per client and endpoint. Cap page sizes, payloads, uploads and query complexity. |
| Inventory | Know every host, version and environment. Retire old versions on a schedule. |
| Logging | Log authentication and authorization failures with enough context to investigate, and alert on patterns. |
| Third-party APIs | Treat data from APIs you call exactly like user input: validate it, limit it, time it out. |
Transport and browser-facing hardening for the hosts that serve your API is covered in the Security Headers Checklist. If your API authenticates with cookies rather than bearer tokens, it also needs CSRF protection.
Testing APIs Safely
- Test only APIs you own or have written permission to assess, in a development or QA environment wherever possible.
- Build authorization tests into the normal test suite: for each endpoint, request it as the wrong user and the wrong role, and assert that it is refused.
- Use static and dynamic analysis in the pipeline, and remember that scanners rarely find authorization flaws, because they do not know whose data is whose.
- Review the specification as well as the code: undocumented endpoints and forgotten versions are findings in their own right.
API Security Learning Path
FAQs
Sources and further reading
- OWASP API Security Project — Project home for the API Security Top 10
- OWASP API Security Top 10 - 2023 — The ten risks and their official descriptions
- OWASP Cheat Sheet Series - REST Security — Transport, authentication, input and error-handling guidance for REST APIs
- OWASP Cheat Sheet Series - Authorization — Deny-by-default and per-request authorization checks
- NIST SP 800-204 - Security Strategies for Microservices-based Application Systems — Authentication, access management and API gateway strategies
- IETF RFC 9700 - Best Current Practice for OAuth 2.0 Security — Current token and authorization-flow security practice