Protect e-commerce APIs by fixing authorization on every object, rate limiting and shaping the flows bots abuse, keeping an inventory of every endpoint, and placing inexpensive checks early so legitimate shoppers feel nothing. The OWASP API Security Top 10 gives a ranked list of what usually breaks in practice.
Which API risks matter most to a shop?
The OWASP API Security Top 10 (2023) lists ten risks. Five map directly onto a storefront.
API1, Broken Object Level Authorization. OWASP says APIs expose endpoints that handle object identifiers, and every function that reads data using an ID from the user needs an authorization check. For a shop: GET /orders/1234. If the server returns any order to any logged-in user, customer data leaks one number at a time.
API3, Broken Object Property Level Authorization. Users can read or write fields they should not, such as setting their own price or discount in an update request.
API4, Unrestricted Resource Consumption. Requests cost bandwidth, CPU and, when you call paid services like SMS or card checks, money. Without limits, abuse becomes both an outage and a bill.
API6, Unrestricted Access to Sensitive Business Flows. OWASP describes flows like buying a ticket or posting a comment that cause harm when used excessively in an automated way, and notes this does not necessarily come from implementation bugs. In commerce, think of coupon guessing, limited stock hoarding, gift card balance checks and account creation sprees.
API9, Improper Inventory Management. More endpoints than anyone remembers, with old versions and debug routes still live.
What does this look like in practice?
A constructed example: a retailer launches a limited sneaker drop. Within a minute, scripts add all stock to carts and hold it. Real customers see "sold out". Nothing in the code is vulnerable in the usual sense. Each request is valid. The problem is the business flow.
Fixes that keep real users unaffected:
- Limit how long stock is held in a cart and how many items one account or address can hold.
- Apply rate limits per account, per IP range and per payment method on the add to cart and checkout endpoints.
- Require a stronger signal only when behavior looks automated, such as many carts in seconds, instead of challenging every shopper.
- Make coupon and gift card lookups slow to repeat and return the same error for wrong and expired codes.
Where do checks belong so checkout stays fast?
Order the work by cost.
- At the edge. Cheap checks first: TLS, basic request size limits, coarse rate limits, known bad sources. These add microseconds.
- At the gateway. Authentication and token validation, schema validation against your API definition, per-client quotas.
- In the service. Object and function level authorization. Only the service knows who owns order 1234, so this check cannot move to the edge.
- Asynchronously. Fraud scoring and deeper analysis that can run alongside the request and act on the next one.
Authorization in the service is the part teams skip, because a firewall or gateway feels like protection. Put it in code and in tests.
What about payment card rules?
If you handle card data, PCI DSS applies. Version 4.0 has requirements for protecting public-facing web applications, including an automated technical solution that detects and prevents web-based attacks. Many shops meet that with a web application firewall. Check the current text and your assessor's interpretation. A firewall is not a substitute for authorization checks in the API, since a valid request for someone else's order looks normal to it.
How to check or apply this
- Build an inventory of endpoints, versions and owners from gateway logs, not from documentation alone.
- Test every endpoint that takes an ID using two accounts: can user A fetch user B's object?
- Reject unknown fields in write requests, and set price and discount server side.
- Identify your sensitive flows: signup, login, cart, checkout, coupon, gift card, password reset. Add limits to each.
- Validate requests against your API schema at the gateway.
- Retire old API versions and debug routes on a schedule.
Quick check
Will rate limiting hurt real customers?
Not if limits are set above normal behavior and tuned per flow. Start in logging mode, check what real users do, then enforce.
Does a WAF protect against broken object level authorization?
Generally no. The request is well formed and the user is logged in. Only the application can decide whether that user may see that order.
Sources
Last reviewed: 18 October 2026.
