Valid input, invalid outcome
Business logic abuse uses valid fields and ordinary operations to violate a business invariant. The attacker can skip a workflow step, repeat a one-time action, combine individually allowed operations, change a price or recipient, exceed a quota, reserve scarce inventory, create many accounts, or exploit a difference between channels.
Generic validation and injection defenses may all work. The defect is that the application accepts a state transition or sequence that should not be allowed.
State and invariants
Write invariants for valuable transitions. An approval applies to one exact transaction and cannot approve itself. A refund cannot exceed the settled amount. A recovery factor cannot be added with only the factor being replaced. A coupon has one owner and one redemption. A user cannot move an object into a tenant they do not control.
Enforce each invariant in the authoritative service and data transaction. Do not rely on a user interface hiding a button or sending steps in the expected order. Bind price, object, actor, approval, and expiry to the committed action.
Abuse resistance
Map normal, mistaken, automated, and adversarial use. Identify which actions create cost, scarcity, reputation impact, external communication, money movement, authority, or irreversible state. Apply identity-aware quotas, velocity rules, reservations, idempotency, review, and evidence as needed.
Rate limits are not a substitute for authorization or invariants. They bound scale. Use several dimensions, such as actor, tenant, resource, destination, device, and payment instrument, so an attacker cannot rotate one identifier.
Failure and residual risk
Happy-path tests rarely exercise alternate order, repetition, concurrency, or cross-channel behavior. A client-side workflow can be replayed directly against APIs. A global rate limit can harm legitimate tenants and still allow distributed abuse. Manual review can be overloaded or manipulated if it sees only an attacker-written summary.
Pomerium boundary
Pomerium can authenticate a caller and apply route-level policy. It does not know the application's object state, price, workflow, quota, approval, or business consequence. The application must enforce those invariants for every API and user interface path. Pomerium identity can be one input to abuse detection and accountability.
Evaluation checklist
- What invariants protect money, authority, scarce resources, external effects, and irreversible state?
- Can a caller skip, reorder, repeat, race, or combine valid operations?
- Are invariant checks and the state change committed atomically?
- Do every user interface, API, batch, and administrative path apply the same rules?
- Are quotas keyed to the identities and resources that represent real cost?
- Do tests include automation, multi-account use, concurrency, rollback, and partial failure?
