business-logic-audit

Inventory all implicit business rules in the flow, classify each as an invariant, limit, ownership, transition, or reward, then apply five questions: where is it enforced, can it be bypassed, repeated, reversed, or raced. Confirm each violation with reproducible evidence.

A business logic vulnerability occurs when the system believes an invariant without guaranteeing it, such as enforcing a daily limit only in the frontend or checking ownership only via authentication. Attackers exploit alternate endpoints, extra fields, retries, or race conditions to violate the rule.

Look for read-then-write patterns where the code reads a counter, checks the limit, then writes. Send two concurrent requests that both pass the check before either writes, exceeding the limit. Enforcement should use database constraints, locks, or atomic transactions.

Avoid reporting when enforcement exists in another layer such as a database constraint, when the limit is intentionally soft by product design, or when the assumed rule was never defined by the product. Mark unconfirmed assumptions as SPECULATIVE.

Rules involving transferable value like money, XP, or stock and ownership checks are triaged as highest severity because they enable direct value extraction or unauthorized access. Cosmetic or UI-only rules rank lower in the audit report.