Business Logic Vulnerability

Overview

What it means and why it matters

A business logic vulnerability is a flaw in how an application enforces its own workflow or economic rules, even when authentication and cryptography operate correctly. It often exploits gaps between states or actions.

How it works in practice

An attacker studies payment flows, such as invoice expiry, coupon use, refunds and retries, then finds a sequence of individually valid actions that produces an invalid outcome. Defenses model permitted state transitions, enforce financial invariants and test concurrent and out-of-order requests.

Technical detail without the jargon

Typical invariants include ‘one order is fulfilled at most once’ and ‘total completed refunds cannot exceed refundable value’. Concurrency controls, idempotency keys and server-side checks matter as much as endpoint permissions.

A deeper point to understand

Consider payment fulfillment races where two valid paid callbacks reach separate workers. Each sees the order as unfulfilled and ships goods before either saves the new state. Atomic claim-and-fulfill or a unique business-action record is needed to prevent this financially harmful but technically ordinary concurrency flaw.

Common mistakes and limitations

A properly signed webhook can still be mishandled if it triggers fulfillment twice. Likewise, a valid account may exploit a race condition to create two refunds against the same original payment.

What to check in a real payment system

Test conflicting concurrent refund requests, late webhooks, repeated checkout sessions and race conditions around inventory release. Define invariants such as maximum refundable value and one-time fulfillment. Use atomic database updates and idempotency at the business-action level.

Related concepts

Webhook, Webhook Verification, API Key.

Further reading

OWASP — Business Logic Security.