A firewall or web application firewall can filter traffic, but it cannot decide whether a signed-in caller is allowed to read a particular record, change a particular field, or trigger a sensitive business action. API security depends on those application-specific rules as well as traffic controls—and on managing endpoints, configurations, and dependencies throughout development and runtime.
Why a firewall cannot secure an API by itself
A firewall operates at a boundary: it can allow, block, or inspect requests according to the signals and rules available to it. A WAF may recognize a request payload that resembles SQL injection. But it generally cannot infer an API’s business rules—for example, whether a field named name must be a string shorter than 100 characters. That check requires application-aware schema or business-rule validation.
Nor does a request passing an edge filter prove that its caller has permission to perform the requested action. Authentication establishes who is calling; authorization determines what that caller may do. An API must make those decisions using the specific operation, object, and fields involved. A firewall or gateway can be a useful layer, but it does not replace checks in the application that understands the request.
What the major API security risks cover
The OWASP API Security Top 10 for 2023 is a practical set of categories to use when examining an API. It is awareness guidance, not a measured ranking of which weaknesses are most common or most likely in a particular organization.
Recommended Free Tools
#1 Best Overall
| OWASP category (2023) | What to examine |
|---|---|
| API1: Broken Object Level Authorization | Whether each operation checks that the caller may access the specific object identified in the request. |
| API2: Broken Authentication | Whether the API reliably establishes and verifies the caller’s identity. |
| API3: Broken Object Property Level Authorization | Whether callers can read or change only the object properties they are permitted to access. |
| API4: Unrestricted Resource Consumption | Whether requests can consume excessive resources because relevant usage is not suitably constrained. |
| API5: Broken Function Level Authorization | Whether the caller is authorized to use the requested function or operation. |
| API6: Unrestricted Access to Sensitive Business Flows | Whether sensitive workflows can be triggered or abused without appropriate protections. |
| API7: Server Side Request Forgery | Whether request handling can be induced to make unintended requests from the server. |
| API8: Security Misconfiguration | Whether API-facing components or services have insecure or unintended settings. |
| API9: Improper Inventory Management | Whether the organization lacks a reliable view of its endpoints, versions, or obsolete APIs. |
| API10: Unsafe Consumption of APIs | Whether data or behavior from upstream APIs is used without appropriate safeguards. |
OWASP’s 2023 list was assembled using project-team experience, specialist review, and community feedback; no data was contributed for that edition. Its risk methodology describes the ratings as the result of team consensus, and the ratings do not account for the specific details or impact of a risk in every organization. Use the categories to prompt a local assessment, not as a probability table or substitute for one.
Authentication is only the first permission check
One of the easiest mistakes to miss is treating a valid login or token as permission to access every object named in a request. If an endpoint accepts a user-supplied record ID, the server still needs to check whether that caller may access that record. Changing an ID in a request must not become a way to cross account or tenant boundaries.
Rank #2
OWASP API Security Project guidance is explicit: “Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.” The same principle applies beyond objects: check permission for the function being invoked and for the individual properties a caller can read or modify. Design those checks into server-side operations rather than relying on a user interface to hide unauthorized actions or fields.
How to assess an API’s attack surface
Use the OWASP categories to identify what to examine, then follow a lifecycle approach. NIST SP 800-228 frames API risk and protections across development and runtime for cloud-native systems. It describes pre-runtime and runtime measures, with basic and advanced controls to support incremental, risk-based adoption.
- Inventory: Can the team identify deployed endpoints and distinguish current versions from obsolete, undocumented, or otherwise overlooked ones?
- Identity and authorization: For each operation, does the server check the caller’s rights to the requested object, function, and properties?
- Input and output: Are accepted fields, types, and sizes constrained by the API’s requirements? Does each response return only properties the caller needs and is allowed to see?
- Abuse resistance: Are resource-intensive requests and sensitive business workflows protected by suitable controls and monitoring?
- Configuration and dependencies: Are API-facing components configured deliberately, and are responses from upstream APIs treated as inputs that require appropriate safeguards?
- Lifecycle ownership: Are controls checked before release and while the API is running, with someone responsible for addressing findings?
This checklist is a practical synthesis of the OWASP risk categories and NIST’s lifecycle framing; it is not a verbatim checklist prescribed by either source. NIST SP 800-228 was initially published in June 2025 and updated on March 13, 2026, when appendices listing API risks by category and recommended controls by lifecycle stage were added.
Where a WAF or API gateway fits
A WAF or gateway can contribute to runtime protection by inspecting or filtering traffic and enforcing appropriate edge controls. It can help reduce exposure, but it cannot reliably supply application-specific decisions it does not know, such as whether a caller owns an object or may modify one of its fields. Those decisions belong in the application’s authorization and validation logic.
Rank #4
When evaluating controls or platforms, compare what they actually cover rather than treating “API security” as a single feature. Useful comparison points include pre-runtime and runtime coverage, enforcement of API-aware schemas and authorization semantics, endpoint and version visibility, defenses against resource and business-flow abuse, fit with the existing stack, and operational effort. OWASP and NIST provide risk and control frameworks; they do not rank or endorse vendors.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical starting sequence
- Build the inventory. Identify deployed endpoints and versions, including obsolete or undocumented interfaces that may still be reachable.
- Trace permissions through operations. For each operation that uses a caller-supplied ID, confirm that the server checks access to the referenced object; then check function-level and field-level permissions.
- Constrain requests and responses. Define acceptable fields, types, and sizes, validate them in the application, and limit returned properties to what the caller is allowed to receive.
- Review abuse paths. Identify operations that consume significant resources or enable sensitive workflows, and apply controls and monitoring appropriate to their risk.
- Check configuration and upstream handling. Review API-facing settings and how the application handles data received from other APIs.
- Keep the work active. Check protections before release and during runtime, assign ownership, and prioritize improvements according to the organization’s risks and capacity.
This incremental approach follows NIST’s distinction between pre-runtime and runtime protections and its support for risk-based adoption. It avoids treating a perimeter appliance as a one-time fix for rules that change with the API itself.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteQuick 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.
