OWASP API Top 10: 8 Reviews for Safer Business Integrations

The OWASP API Top 10 highlights common categories of API security risk. For a business application, those risks can affect customer records, bookings, invoices, and connected services. The list helps teams ask better questions, but it is not a complete security test or a certificate.

This article turns the categories into eight practical reviews for a business integration. The eight reviews are an organizing method, not a replacement for OWASP’s ten categories. They cover record access, identity, fields, business actions, resource use, outbound requests, configuration, and external trust.

Use the API-specific list deliberately

The OWASP API Security Top 10, 2023 edition focuses on risks in APIs. It differs from the broader web application list. Confirm the edition in a review plan so the team discusses the same categories.

An API can serve a website, mobile app, partner integration, or internal service. Hiding an action in the interface does not secure the underlying endpoint. The server must decide whether each request is allowed.

For example, a customer portal may show only the signed-in customer’s invoices. If its API accepts another invoice reference without checking ownership, the interface filter does not protect the data. That is why a review must follow requests beyond the visible screen.

1. Review access to every business object

A business object is a record such as a job, quote, invoice, or attachment. For each operation, ask whether the caller may access that specific record. A valid sign-in alone does not answer the question.

Use safe accounts from different customer organizations. Retrieve an allowed record, then attempt the same operation against the other organization’s record in the authorized test environment. Check reads, updates, downloads, and deletes separately.

OWASP’s broken object level authorization guidance explains this category. A random-looking identifier can reduce guessing, but it does not replace the ownership or access check.

Also review indirect references. An attachment may inherit access from a job, while an export may contain many records. The same boundary needs to hold across every route that exposes the underlying information.

2. Review authentication and session handling

Authentication establishes the caller’s identity. Review how the API issues, accepts, expires, and revokes credentials. Include service accounts and partner tokens as well as human users.

Check what happens after a user signs out, changes credentials, or loses access. The application should follow its documented session policy. Old credentials should not remain useful simply because a background integration forgot to refresh its access state.

Use limited service identities for integrations. A scheduling connector should not need the same access as a platform administrator. Keep secrets out of code, URLs, and routine logs.

Test failed authentication and recovery paths. Error responses should help legitimate callers understand the problem without exposing secrets or unnecessary account details. Rate and abuse controls need to match the risk of the authentication flow.

3. Review which fields callers may read and change

Record access and field access differ. A technician may need a job’s address and instructions without needing the customer’s credit terms. A customer may update a phone number but not an internal approval status.

Define allowed input and output fields for each operation. Avoid accepting an entire client-supplied object without checking its properties. An unexpected field should not silently change a privileged business value.

Use explicit response models where practical. Returning a whole database record can reveal fields that the interface never displays. Review exports, search results, and nested objects too.

Test extra properties with safe data. For example, attempt to submit an internal status through a customer update operation. Confirm that the service rejects or ignores it according to the contract and leaves the protected value unchanged.

4. Review functions and sensitive business flows

Some actions require a higher role even when the caller can view the underlying record. Approving a discount, issuing a refund, and changing an assignment may need separate permission checks.

List those functions explicitly. Then test them through roles that may and may not perform the action. The endpoint should enforce the rule even when the caller constructs a request outside the normal interface.

Also consider abuse of a permitted flow. A caller may legitimately request a quote but should not be able to flood the system with expensive or disruptive requests. Business limits may need to reflect account, user, resource, and time.

For a booking system, review repeated reservations and cancellations. The question is not only whether a request is syntactically valid. Ask whether the pattern undermines availability or creates operational work beyond the intended use.

5. Review resource consumption and failure limits

An API request can consume database time, storage, external service credits, or background workers. Identify expensive operations and define limits that fit the business. A simple request can still trigger costly work.

Examples include large exports, repeated file uploads, and searches with broad filters. Set appropriate bounds on input size, pagination, processing time, and concurrency. Check that limits apply to the actual workload rather than only the visible page.

Test behavior at the boundary in an approved environment. The service should reject or defer work clearly without leaving partial records or exhausting resources. Avoid using production as an uncontrolled load experiment.

Track external costs too. An endpoint that sends messages or calls a paid lookup service can create expense even if the database remains healthy. Include those effects in abuse review and monitoring.

6. Review outbound requests and external destinations

Some APIs fetch a URL or send data to a supplied destination. That creates a trust boundary. Review which destinations the server may contact and how it validates them.

For example, a document import feature might retrieve a file from a URL. The application should not treat every user-supplied address as an approved server destination. Use a design that limits the feature to its intended sources.

Review redirects, internal network reachability, and the information included in outbound requests. A destination check that covers only the first URL may not match the final request path.

Keep the business need narrow. If the feature only imports from one approved document service, a general fetch-anywhere interface may be unnecessary. Reduce the capability rather than relying on a long list of exceptions.

7. Review configuration and API inventory

Maintain an inventory of endpoints, versions, owners, and intended users. Old test routes and forgotten versions can remain accessible after the main application moves on. A gateway list may not include every deployed service.

Record where each API runs and how it authenticates callers. Include partner-facing and internal interfaces. Internal placement can reduce exposure, but it does not eliminate the need for access controls.

Review default settings, debug output, error handling, and deployment differences. A secure staging configuration does not prove production uses the same controls. Keep configuration evidence with the release.

Anomoz’s article on API gateway decisions explains the gateway’s role. It can support common controls, while each service still needs to enforce business-specific rules.

8. Review trust in connected APIs

Data from another service still needs validation. A partner response may be malformed, incomplete, delayed, or inconsistent with the contract. Do not assume external data is safe merely because it comes from a familiar vendor.

Check fields, sizes, types, and references before using them. Handle timeouts and partial failures deliberately. A missing supplier value should not silently become a valid price or customer identifier.

Use contract checks where services change independently. Anomoz’s guide to contract testing explains how to detect incompatible expectations. Security review adds questions about trust and consequences beyond ordinary compatibility.

Also review retries. An uncertain response after a write can cause duplicate invoices or bookings. Use supported duplicate protection and a clear recovery route rather than repeating consequential operations blindly.

A worked example: a field-service customer API

Suppose customers can view jobs, upload photos, and request a new appointment. Begin with an endpoint inventory and two safe customer accounts. Map each operation to its records, fields, role, and external effects.

Test whether one customer can reach another customer’s job or attachment. Then check whether the customer can submit internal fields such as assigned technician or approval status. Confirm the protected records remain unchanged.

Next, review upload limits and appointment request behavior. Test supported boundaries without creating real dispatch work. Finally, inspect the destination service contract and error handling for the scheduling integration.

Record findings with the affected operation, business impact, steps to repeat, and expected control. Keep the test evidence private and safe. A useful report lets developers repair the root cause and lets reviewers confirm the fix.

Turn categories into an ongoing review process

The OWASP API security top 10 provides a useful starting vocabulary. The application still needs a threat review based on its actual data, users, and business effects. Some risks will sit outside the list.

Combine design review, code analysis, service tests, and appropriate hands-on assessment. Anomoz’s article on security testing in software testing explains how different methods contribute evidence.

After repair, retest the original issue and related operations. A shared authorization fix may affect several endpoints. A local patch may leave the same flaw in another version or download route.

Keep evidence useful and limited

Record enough detail to explain the finding without copying unnecessary private records. Use safe identifiers, redacted responses, and restricted access. Security evidence can itself contain sensitive information.

Track owner, priority, repair status, and retest outcome. Do not close a finding solely because the code changed. Confirm the intended control now works and that the ordinary permitted flow still succeeds.

Review the inventory after new integrations and major releases. New endpoints, roles, and external services create new assumptions. Keeping the list current makes the next review faster and more complete.

Review changes at the business boundary

A new field or endpoint can change who can see or influence a record. Include security questions in API change review, especially when a route gains exports, attachments, or bulk actions. Small interface changes can create large effects.

Ask the owner to identify the caller, record, permitted fields, and possible external cost for each important operation. Then update the test plan to reflect the change. Keeping those questions close to development makes later assessment more focused.

Use a simple evidence checklist for every repair: the denied request fails, the allowed request succeeds, and no unintended record or field changes. Add the affected API version and deployment reference. This preserves the business boundary as a testable promise rather than a general claim about secure coding.

Review the request and the business effect

Use the risk categories to examine who can act, which data they can reach, and what each request can cause. Then test the controls and track repairs. The strongest review connects API behavior to real business consequences.