To secure an API, enforce authorization for every object, field, and privileged action, then limit what each request can make the system do. HTTPS and reliable authentication matter, but neither proves that a caller is allowed to access a particular record. Use OWASP’s API Security Top 10 (2023) as a map of risks to review—not as a statistical ranking—and pair it with the implementation guidance in OWASP’s REST Security Cheat Sheet.
What risks should an API security review cover?
The OWASP API Security Top 10 (2023) groups API-specific risks into ten categories. Its order is not a measurement of how often each vulnerability occurs: OWASP says its public call for data did not produce data suitable for relevant statistical analysis. The categories are a practical way to organize a review, not a substitute for assessing your API’s own threats.
As an Amazon Associate I earn from qualifying purchases.
| OWASP category | Review focus |
|---|---|
| API1: Broken Object Level Authorization | Can a caller access another user’s record by changing an identifier? |
| API2: Broken Authentication | Can credentials or tokens be guessed, stolen, misused, or accepted after they should no longer be valid? |
| API3: Broken Object Property Level Authorization | Can a caller read or change fields they should not control? |
| API4: Unrestricted Resource Consumption | Can a request consume excessive compute, bandwidth, storage, or paid services? |
| API5: Broken Function Level Authorization | Can a lower-privilege caller invoke administrative or otherwise restricted actions? |
| API6: Unrestricted Access to Sensitive Business Flows | Can an automated caller abuse a sensitive workflow, even if individual requests are authorized? |
| API7: Server Side Request Forgery | Can caller-controlled input make the server contact unintended destinations? |
| API8: Security Misconfiguration | Are unsafe defaults, exposed interfaces, or overly broad settings leaving the API open? |
| API9: Improper Inventory Management | Are undocumented, obsolete, or forgotten API versions and endpoints still reachable? |
| API10: Unsafe Consumption of APIs | Does the service trust data or behavior from an integrated API without sufficient validation? |
This API-specific list does not cover every application risk. Injection flaws and vulnerable components, for example, can still affect APIs and need attention even though they are not separate categories in this Top 10.
Free tools Windows power users keep installed
One-click scans. No signup required.
How should authorization be enforced?
Make an authorization decision at the point where the API accesses data or performs an action. A successful login establishes identity; it does not grant access to every record or capability. OWASP’s API1:2023 guidance calls for object-level authorization checks in every function that accesses a data source using an ID supplied by the user.
#1 Best Overall
Check access to each object
- For every endpoint that accepts a record ID or other user-controlled selector, verify that the authenticated caller may access that specific object.
- Apply the check on every relevant operation, including reads, updates, deletes, and actions that trigger a change elsewhere. Do not rely on an identifier being difficult to guess.
- Test with two accounts or roles: try to use one caller’s credentials to access or change the other caller’s records.
Control fields and functions separately
- Allow only explicitly permitted fields to be read or written. Avoid returning sensitive properties simply because they are part of the underlying record, and do not accept arbitrary fields in update requests.
- Check permissions for privileged functions on the server, including administrative operations. Hiding an action in a client interface does not restrict access to its API endpoint.
- Review sensitive business flows for automation or repeated use that could cause harm even when each individual request passes ordinary authorization checks.
How should authentication, transport, and credentials be protected?
Require HTTPS for API endpoints, as OWASP’s REST Security Cheat Sheet advises. Use an identity and token approach suited to the API’s clients and service model, and validate credentials rather than treating possession of an API key as proof of strong identity or permission.
- Do not put passwords, API keys, or tokens in URL parameters. URLs can be captured in logs and other records.
- Do not use an API key alone to protect sensitive or high-value resources, particularly when the key is distributed to clients that cannot keep it confidential.
- For high-privilege service-to-service connections, consider mutual TLS when it fits the architecture and operational model.
- Review how credentials are issued, validated, stored, rotated, and revoked; a secure login or token mechanism does not replace the authorization checks described above.
What should be validated at each trust boundary?
Treat both incoming requests and data received from integrated services as untrusted. Validate expected type, format, range, and length before using values; use secure parsers and enforce request-size limits. Reject inputs that fall outside the API’s contract rather than allowing downstream code to interpret them unpredictably.
Rank #2
Validate requests before processing
- Define acceptable types, formats, ranges, and maximum lengths for request fields, then enforce those constraints on the server.
- Set payload and upload limits, and use parsers configured to avoid unsafe or excessive work.
- For fields that select a resource or influence a destination, validate against the intended set of values rather than assuming that syntactically valid input is safe.
Validate upstream responses before reuse
An integrated API’s response is not automatically trustworthy. OWASP’s API10:2023 guidance says to validate and properly sanitize data received from integrated APIs before using it.
- Use encrypted communication with upstream services and validate their returned data against the structure and values your application expects.
- Restrict redirect destinations where redirects could lead to unintended hosts, and set timeouts and resource bounds for outbound calls.
- Do not pass unvalidated upstream content into queries, commands, templates, or other sensitive downstream operations.
How can requests be kept from exhausting resources or enabling abuse?
Set limits according to the work and cost an operation can trigger, not just the number of HTTP requests. A request-per-minute threshold may be inadequate when a single request can launch an expensive computation, process a large batch, return many records, or incur third-party charges.
Rank #3
- Limit request frequency per relevant client or user, and set payload and upload size caps.
- Set execution timeouts and bounds on batch sizes, operation counts, and the number of records returned.
- Apply pagination limits so callers cannot request unbounded result sets.
- For APIs that incur per-request provider charges, set spending limits or billing alerts that fit the service’s risk tolerance.
- Review sensitive business workflows for abuse patterns as well as ordinary resource consumption; apply controls appropriate to how those workflows can be exploited.
Which configuration and inventory controls are easy to overlook?
Security depends on the deployed API surface, including older versions and operational interfaces—not only the endpoints developers intend clients to use.
- Maintain an inventory of API hosts, versions, and endpoints. Remove obsolete endpoints and versions that are no longer needed.
- Restrict management and debug interfaces; do not expose them as ordinary public API features.
- Configure CORS narrowly for browser clients that need cross-origin access. CORS is a browser policy, not an authorization mechanism for all API callers.
- Return generic error messages to clients rather than stack traces or internal implementation details.
- Harden relevant infrastructure and application settings instead of relying on default configurations.
How should API security checks fit into ongoing operations?
Use the OWASP categories to organize reviews across the API lifecycle: design, implementation, deployment, and maintenance. The following checks make the guidance actionable without treating a single review as permanent assurance.
Rank #4
- API Security in Action
- Manning Publications
- ABIS BOOK
- At design time: identify sensitive records, fields, actions, workflows, external dependencies, and operations with unusually high resource or provider cost. Decide which callers may use each capability.
- During implementation: add object-, property-, and function-level authorization at the server-side access points; validate requests and upstream responses; and define operational bounds for expensive work.
- Before deployment: review the exposed hosts, versions, endpoints, management interfaces, CORS settings, and client-facing error behavior. Remove interfaces that are no longer required.
- In production: monitor security-relevant events and resource or provider spending. Sanitize logged data to prevent log injection, and do not record secrets.
- After changes: revisit authorization boundaries, validation rules, limits, and the API inventory when endpoints, roles, workflows, or integrations change.
OWASP’s API Security Top 10:2023 and REST Security Cheat Sheet provide a useful baseline, but generic application risks such as injection and vulnerable dependencies remain in scope. No single checklist can replace controls tailored to the API’s data, callers, and operational costs.
Quick Recap
Best Value
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.
