API authorization testing: separating evidence from assumptions

An API assessment needs more than the label “broken authorization.” The team fixing a problem needs the original role, action, object and observed result. Without them, an assumption can easily be mistaken for evidence of broader access.

This is a methodological review of an already published retail case study, not a new customer assessment. It discloses no additional customer data. Route names and numerical counts in the source case were changed for anonymity and are not used as product performance statistics.

Authentication and object access are different checks

A device token may show that a request comes from a known device. That does not establish permission to read any customer's order. The server must check whether the caller may perform the specific action on the specific object.

This class is described in OWASP API1:2023 — Broken Object Level Authorization. Server-side object permissions are necessary for object operations; authentication at the endpoint does not replace them.

What the published case actually confirmed

The historical order service accepted a device token without checking order ownership. Requests returned other customers' order records containing customer data. That is observed object access, rather than a conclusion based only on an HTTP success status.

With the customer's authorization, cancellation and payment-method changes were separately tested on completed orders from previous years. The service confirmed the operations and returned a payment link. No payment was made. Access to current orders in the newer system was not confirmed.

This supports a narrow conclusion about the historical service and the tested operations. It does not demonstrate arbitrary access to every order, an actual transfer of money, or broken authorization across all company applications.

Why production and a replica must remain separate

In another chain from the same case, file writes were confirmed on the production video-conferencing service. Later steps leading to command execution and use of a token-signing key were reproduced in a controlled replica.

Those results have different boundaries. A technical path demonstrated in a replica matters for risk assessment, but does not prove that every step ran in production. The report should identify the environment beside each material result.

The minimum useful evidence record

For each finding, record:

1. Conditions: the environment, version, role, access type and agreed assessment limits.
2. Expected behavior: who may perform the action on the selected test object.
3. Observation: the action and result sufficient to establish impact. Redact secrets and unnecessary personal data from the working report.
4. Boundaries: objects and actions that were not tested or could not be confirmed.
5. Next step: the permission check to review, the intended fix and retest conditions.

Do not expand the assessment merely to make a report more impressive. Data-changing tests need suitable objects and explicitly agreed operations in advance.

Remediation and retesting

For broken object authorization, the remediation direction is a server-side check of the caller's permission to perform the relevant operation. A hidden interface control or a hard-to-guess identifier does not replace that check.

A useful retest repeats the original negative scenario and confirms that a legitimate user's permitted operation still works. If the original access, test object or comparable version is unavailable, describe the retest as limited rather than claiming a verified fix.

These are recommendations for checking a fix. No new retest of the customer's system was performed to prepare this article, and no such result is claimed here.

Using this when evaluating a solution

In a pilot, evaluate reproducibility, clear limits and the usefulness of the next step. Finding count alone does not establish assessment quality. Ask how results distinguish a hypothesis, a confirmed observation and an untested area.

To discuss an assessment of your system, use the request form. Questions about the article can be sent to the Sentra team.