How should security teams test authorization in commerce APIs?

Why This Matters for Security Teams

Commerce APIs concentrate business logic, payment workflows, and customer data in a small number of mutation paths, which makes authorization flaws high impact and often hard to spot in ordinary functional testing. Teams usually focus on authentication and input validation, but the real risk is whether an authenticated user can act on a resource they do not own. That concern maps directly to control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement and accountability must be demonstrable.

Authorization testing is also a fraud control, not just an application security exercise. If one customer can update another customer’s cart, shipping address, order state, or payment method, the failure can become financial abuse, data exposure, or downstream dispute handling. Current guidance across application security programmes suggests that object-level controls need to be tested as implemented, not assumed from route design or role names. In practice, many security teams encounter broken object-level authorization only after a support case, refund dispute, or incident response review has already exposed the gap.

How It Works in Practice

The most reliable approach is to test each sensitive mutation with two identities: a token belonging to the attacker and a resource identifier belonging to a victim. The question is not whether the endpoint is reachable, but whether the backend verifies ownership, tenancy, or delegated authority at the point where the state change happens. This should be repeated across REST, GraphQL, and any API gateway, BFF, or reverse proxy layer, because checks sometimes differ by entry point.

For commerce APIs, the test set should cover the operations most likely to carry business impact:

• Cart edits such as quantity changes, item removal, and promotion application
• Address changes, shipping method changes, and delivery re-routing
• Order cancellation, returns, refunds, and payment instrument updates
• Account-linked operations such as saved cards, wish lists, and subscription changes

Validation should compare expected denials and error consistency. A secure implementation usually returns a controlled authorization failure without revealing whether the victim resource exists. Where APIs use GraphQL, security teams should inspect field-level and resolver-level enforcement, not only the top-level operation. Where proxies perform coarse filtering, teams should confirm that downstream services still enforce the same decision, because edge controls can be bypassed by alternate paths or direct service calls. OWASP’s API security guidance and the OWASP Authorization Cheat Sheet remain useful references for structuring these checks.

Testing should also include negative cases for ID manipulation, object substitution, replayed tokens, and cross-tenant access where a platform serves multiple merchants or brands. If the environment uses service-to-service calls, the same logic applies to non-human identities, because internal APIs can be over-trusted just as easily as customer sessions. These controls tend to break down when authorization is split between gateway rules and microservice code because the two layers drift and the backend stops re-checking ownership.

Common Variations and Edge Cases

Tighter authorization testing often increases test maintenance and can slow release cycles, so organisations need to balance coverage against the cost of building realistic identity and data fixtures. That tradeoff is especially sharp in commerce systems with promotions, split shipments, partial refunds, and marketplace seller flows, where the ownership model is not one-to-one.

Best practice is evolving for APIs that expose nested relationships or batch mutations. A single request may legitimately touch multiple resources, and there is no universal standard for how every GraphQL resolver or bulk endpoint should express denial. In those cases, teams should document the expected authorization boundary per object and per action, then test both the happy path and the cross-ownership path explicitly. Where roles are involved, RBAC should not be treated as sufficient by itself if the business rule is actually object ownership or transaction state.

Edge cases also arise when customer support, fraud operations, or fulfilment systems have legitimate override privileges. Those exceptions should be narrow, logged, and reviewable, with step-up controls where practical. If the same API supports human operators and service accounts, separate policy paths are usually needed so that elevated operational access does not accidentally become customer-accessible behaviour. For broader control mapping in regulated environments, teams often pair API testing with NIST Cybersecurity Framework guidance to keep detection, response, and accountability aligned.

Related resources from NHI Mgmt Group

• How should security teams test REST APIs for broken authorization?
• How should security teams test GraphQL APIs for authorization bypasses?
• How should security teams test AI agents that can call tools and APIs?
• How should security teams handle authentication and authorization errors in APIs?