An application programming interface, or API, lets software ask another service to do something. A request can be correctly written and still produce a harmful business result. This happens when the service checks the format of the request but misses a rule about how the feature should be used.
Understand the idea
Start with the promise the feature makes. A voucher might be usable once, a refund might require an approved purchase, or a payment might have a daily limit. Those rules must remain true across retries, repeated requests, and actions happening at the same time.
- Allowed action
A legitimate feature accepts a request.
- Repeated use
Timing or repetition changes its business effect.
- Invariant
The server enforces the rule at the point of action.
A practical example
Imagine a shop that checks whether a voucher is unused before applying a discount. Two requests arrive together and both pass that check. A useful review asks whether the service records the voucher’s use as part of the same protected operation that grants the discount.
What to do next
- Keep decisions on the server. Recalculate prices, permissions, and eligibility from trusted records. A client-supplied total is a request, not the accounting record.
- Make state changes atomic. The check and the update must behave as one protected operation. Database constraints, transactions, or appropriate locking may enforce this better than a separate preliminary check.
- Handle retries deliberately. Use scoped idempotency identifiers, store the completed outcome, and reject reuse with different transaction details.
- Limit the cost as well as the count. Apply bounds to batch size, pagination, execution time, and expensive operations. A small number of costly queries can still exhaust a service.
How to check the result
A successful test shows that the intended transaction works while repeated or conflicting requests cannot break the business rule. Use controlled data and a test environment approved by the service owner.
Our gateway accepts the request. Does that mean it is safe?
A gateway cannot decide every business rule. The application must enforce ownership, transaction limits, and valid state transitions for the workflow itself.
Sources and useful guides
The following resources provide background and more detailed guidance. Use the sections that match your service and situation.
