What are business logic flaws?

A business logic flaw is a gap between the rules a product is supposed to follow and what the code actually enforces. The inputs are valid and the code runs without errors, but a user can still do something the business never intended, such as skip a step, apply a discount twice or approve their own request. CWE tracks these under business logic errors (CWE-840), and OWASP places them under insecure design.

Updated October 2026

Why it matters

Logic flaws touch the parts of an app that matter most: money, approvals and who owns what. They can let a user get paid features for free, move funds without approval, or change a record that should have been locked. Because the app behaves normally, these issues can run for months before anyone notices.

They are also specific to each product. No public list of known bugs will include yours.

Logic flaws also tend to survive code review. Each line looks correct in isolation, and the reviewer checks what the code does, not what it fails to stop. The missing rule is invisible unless someone holds the product intent in mind while reading. That is why written rules and explicit negative tests matter so much for this class.

A simple illustration

Acme Corp has an expense tool. Members submit expenses and admins approve them. The rule is simple: nobody approves their own expense. The approve endpoint checks that the caller is an admin, but an admin who also submits expenses can approve their own.

Vulnerable check:

def approve
  expense = current_org.expenses.find(params[:id])
  authorize! :approve, Expense  # admin only
  expense.update!(status: "approved")
end

Corrected check:

def approve
  expense = current_org.expenses.find(params[:id])
  authorize! :approve, Expense
  raise Forbidden if expense.submitter_id == current_user.id
  raise Conflict unless expense.status == "submitted"
  expense.update!(status: "approved", approver_id: current_user.id)
end

The fix enforces two business rules on the server: no self-approval, and approval only from the submitted state. It also records who approved.

Why automated scanners often miss it

A scanner sees a valid request and a successful response. It has no idea that self-approval is forbidden, or that an order must be paid before it ships. Those rules are not in the HTTP traffic. They live in your product spec, your support tickets and the heads of your team. Finding logic flaws needs a model of what the app is for, and then a deliberate attempt to break that model.

How to prevent it

• Write the business rules down, including what must never happen.
• Model workflows as explicit state machines and reject invalid transitions on the server.
• Enforce separation of duties where the business requires it.
• Recalculate prices, totals and limits on the server; never trust client values.
• Make sensitive actions idempotent and record who did what.
• Add tests for the "must never happen" cases, not only the happy path.

How to test your own app for it

Only test software you own or have written permission to test.

• For each workflow, list the steps and confirm the server enforces their order.
• Confirm every limit (quantity, discount, quota) is enforced on the server.
• Confirm separation of duties holds for each role combination.
• Review what happens when a step is repeated, skipped or cancelled midway.
• Have someone outside the feature team read the rules and try to find gaps.

How Wakefield helps

Wakefield's blackbox agents sign in as every role your app has (admin, member, guest), map its pages and APIs, build a model of who should see what, then try to cross user, tenant and role lines. A separate verifier replays each finding with a live exploit and a negative control, so you only see bugs that reproduce. See Blackbox testing.

Related topics