To secure an API, map each risk in the OWASP API Security Top 10 (2023) to a specific surface in your system: object identifiers, login and recovery flows, response properties, privileged functions, expensive operations, business workflows, outbound requests, configuration, version inventory, and third-party calls. Then give each surface a concrete control and a test that proves the control works. The list is a checklist for design and review. It is not a complete implementation standard.
What the OWASP list does and does not cover
The OWASP API Security Project publishes the OWASP Top 10 API Security Risks – 2023 list. It names ten risk categories and is intended as an awareness resource. OWASP states that the Top 10 does not replace other Top 10 lists, so a team still needs the relevant standards for its protocols, platforms, and data types. The 2023 edition is the one this article follows. Check the OWASP API Security Project page for any newer edition before you cite the list in a policy or contract.
As an Amazon Associate I earn from qualifying purchases.
The list is also not a frequency ranking. OWASP’s methodology and data page explains that the 2023 update reviewed publicly available API incidents from 2019 to 2022 and ran a three-month public call for data. That call did not produce data suitable for relevant statistical analysis, and the prevalence ratings were set by consensus among project team members based on experience. Use the ordering to structure education and review, not to estimate how often a weakness appears in the wild.
Map the ten risks to your API surfaces
The most useful first step is an inventory of what your API actually exposes. Each row below pairs a risk with the surface where it shows up and the control you should be able to point to during review.
#1 Best Overall
| Risk | Where it shows up in your API | Control to verify |
|---|---|---|
| API1:2023 Broken Object Level Authorization | Any route, query, or body field that accepts an object ID | The caller’s identity is compared with the object’s owner or tenant before the read or write |
| API2:2023 Broken Authentication | Login, token issuance, password reset, email and phone changes | Rate limits, anti-brute-force protection, re-authentication for sensitive changes, MFA where possible |
| API3:2023 Broken Object Property Level Authorization | Response bodies and writable fields on create and update calls | Field-level rules limit what each role can read and which fields it can change |
| API4:2023 Unrestricted Resource Consumption | Large queries, file uploads, exports, and calls to paid downstream services | Limits on request size, page size, and request rate, plus budgets for downstream cost |
| API5:2023 Broken Function Level Authorization | Administrative and privileged endpoints | Role or permission checks on every privileged function, denied by default |
| API6:2023 Unrestricted Access to Sensitive Business Flows | Workflows that cause harm when automated, such as account creation, coupon redemption, or inventory holds | Abuse controls such as per-account limits, step-up verification, and workflow state checks |
| API7:2023 Server Side Request Forgery | Features where a user supplies a URL or hostname the server will fetch | Validation of destinations before the server makes the request |
| API8:2023 Security Misconfiguration | Gateways, servers, error handling, CORS, and debug settings | A recurring configuration review with a recorded owner |
| API9:2023 Improper Inventory Management | Hosts, deployed versions, and endpoints, including deprecated ones | An inventory that matches what is deployed, with retirement dates for old versions |
| API10:2023 Unsafe Consumption of APIs | Calls to third-party APIs and the data they return | Transport security, authentication, and validation applied at the integration boundary |
These are risk areas, not a claim that every API has every weakness. A small internal API may have no outbound fetch feature, so API7 would not apply to it. A public API with user-generated URLs needs that row treated as a priority.
Start with object-level authorization
OWASP’s guidance for API1 is direct: object-level authorization checks should be considered in every function that accesses a data source using a user-supplied ID. The check belongs in the code path that reads or changes the object. A gateway can confirm that a token is valid, but it usually cannot know whether order 8841 belongs to the caller.
- List every route, query parameter, and body field that accepts an identifier, such as
/orders/{orderId},?accountId=, or acustomerIdin a JSON body. - For each one, load the object and compare its owner or tenant with the authenticated caller before reading, updating, or deleting it.
- Check write methods separately. A user who can read an object may still be unauthorized to update or delete it.
- Return the same error for a missing object and for an object owned by someone else, so the response does not confirm that the ID exists.
- Test with two accounts. Request account B’s object IDs using account A’s token for each method, and confirm the response contains no data from B.
GET /v1/orders/8841 Authorization: Bearer <token for user A> Expected: 404 Not Found (or 403), with no order fields in the body Failure: 200 OK with order 8841 belonging to user B
Authentication is a system, not just token issuance
OWASP’s API2 guidance covers more than how a token is issued. It recommends treating credential recovery and forgotten-password endpoints the same way as login endpoints, with protections against brute force, rate limiting, and lockout. The same page recommends these additional controls:
Recommended Free Tools
Rank #2
- Require re-authentication for sensitive operations, such as changing the account owner’s email address or the phone number used for two-factor authentication.
- Implement multi-factor authentication where possible.
- Apply anti-brute-force mechanisms to every authentication endpoint.
- Check new passwords against weak-password rules.
Two boundaries need to be stated explicitly in design reviews. First, OWASP says: “API keys should not be used for user authentication. They should only be used for API clients authentication.” Use an API key to identify the calling application, and establish the end user through an authentication flow built for that purpose. Second, the same OWASP page states: “OAuth is not authentication, and neither are API keys.” An access token issued through OAuth authorizes a request; it does not, by itself, prove who the user is. Review each flow to confirm that user identity is established by a mechanism designed for that job.
Property and function level authorization
Property level (API3)
Object-level checks decide whether a caller may access a record. Property-level checks decide which fields inside that record the caller may read or change. Two common failures are over-broad responses, where a serializer returns internal fields such as internal notes or risk scores, and mass assignment, where a client sends a field such as role or isAdmin in an update and the server writes it. Define an allowlist of writable fields for each role, and build responses from that allowlist rather than from the full database record.
Function level (API5)
Function-level authorization asks whether this role may call this function at all. Being logged in is not enough for administrative endpoints such as user management, refund approval, or configuration changes. Check the role or permission on every privileged route, deny by default, and do not rely on an undocumented or hidden URL to keep an admin function private. Test each privileged route with a low-privilege token.
Rank #3
Resource consumption and sensitive business flows
Unrestricted resource consumption (API4)
OWASP flags resource consumption as a risk that extends beyond server load. Costs can accrue through dependent services, so a single cheap request can trigger an expensive message, lookup, or export. Put limits in place for each of these:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Maximum request body size and maximum page size for list endpoints.
- Rate limits per client, per account, and per IP address, applied separately to expensive operations.
- Time limits on long-running queries, exports, and uploads.
- Budgets or quotas for calls to paid downstream services such as SMS, email, or mapping APIs.
Sensitive business flows (API6)
API6 covers workflows that are harmless when used once but damaging when automated. Examples include account creation, coupon redemption, ticket purchase, and inventory holds. OWASP’s point is that the risk is business harm and operational cost from automated abuse, not only a conventional technical failure. Start by listing the flows where automation would cause loss, then apply controls such as per-account and per-device limits, step-up verification for suspicious activity, and workflow state checks. For example, a checkout call should fail if the cart is not in a payable state, even if the caller has a valid token.
Outbound requests and third-party data
Server-side request forgery (API7)
API7 applies when your server fetches a remote resource because a user supplied the destination, such as a URL for a webhook, an image import, or a document preview. OWASP’s recommendation is to validate user-supplied destinations before the server fetches them. In practice, that means:
Rank #4
- API Security in Action
- Manning Publications
- ABIS BOOK
- Allow only the schemes and hostnames the feature needs.
- Resolve the hostname and reject private, loopback, and link-local addresses before connecting.
- Re-validate the destination after any redirect, or do not follow redirects.
- Avoid returning the raw response from the remote server to the user.
Unsafe consumption of APIs (API10)
OWASP’s description of API10 names the core problem: “Developers tend to trust and not verify the endpoints that interact with external or third-party APIs, relying on weaker security requirements such as those regarding transport security, authentication/authorization, and input validation and sanitization.” Treat every third-party response as untrusted input. Verify the provider’s TLS certificate through the standard library defaults rather than disabling verification, authenticate to the provider with its supported mechanism, set timeouts and response size limits, and validate fields before they reach a database, template, or downstream service.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Configuration, inventory, and versions
API8 and API9 are operational risks that code review alone will miss. For API9, OWASP flags improper inventory management because undocumented or deprecated API versions and exposed debug endpoints can remain available. Build the inventory from more than the documentation: compare your gateway routes, server logs, and the code’s route table, and record every host, deployed version, and endpoint. Each deprecated version needs a retirement date and a check that it is actually unreachable after that date.
For API8, review the configuration of the API and the systems around it as an ongoing task. The review should cover debug and verbose error settings, CORS policy, default credentials, unused HTTP methods, and TLS settings on every host in the inventory. Assign an owner to the review so that it happens after deployments and infrastructure changes, not only during the initial build.
Best Value
Scope and where to go next
OWASP describes the Top 10 as an awareness document, and it does not replace protocol or platform standards. For authentication flows, consult the specifications your identity provider implements; for framework behavior, consult your framework’s security documentation. The OWASP list tells you what to look for and where, and the controls above give you a starting point for each area.
The Bottom Line
Begin with the inventory (API9) and object-level authorization (API1). An endpoint you have not catalogued cannot be tested, and object-level gaps expose data directly to any authenticated caller. Once those are covered, work through authentication, property and function authorization, resource limits, business-flow abuse, outbound requests, and configuration in that order, and attach an owner and a test to each control.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
