Some of the most expensive application vulnerabilities contain no unsafe function and no obvious bug. The code does exactly what it was written to do. The problem is that what it was written to do can be abused. These are business logic flaws, and because a scanner has no idea what your business is supposed to allow, finding them is a job for people.

What do business logic flaws look like?

  • Price and quantity tampering. The server trusts a price or total sent by the client, or accepts a negative quantity that turns a purchase into a refund.
  • Skipped steps. A multi-step flow such as checkout, onboarding or approval that can be completed by calling the last step directly.
  • Coupon and credit abuse. Codes that can be applied repeatedly, stacked or used past their limits.
  • Self-approval. A user who can approve their own expense, change or access request.
  • Race conditions. Two simultaneous requests that both pass a balance or stock check before either one updates it.
  • Enumeration and scraping. Sequential IDs and unlimited lookups that expose the whole customer base.

Start by asking what should never happen

Before reading the code, write down the rules the business depends on. "An order total can never be less than the sum of its items." "A user can never approve a request they created." "A voucher can only be redeemed once." Then read the code looking for any path that breaks a rule. This inverts the usual review mindset from "does this work?" to "how could this be made to misbehave?"

Check state transitions and trust

  • Is every state change validated against the current state on the server? Can an order go from "cart" to "shipped" without "paid"?
  • Which values come from the client, and which are recalculated or looked up on the server?
  • Are hidden form fields, client-side checks and front-end flow control being treated as security controls?

Look for concurrency problems

Any "check, then act" sequence is a candidate for a race condition: read a balance, verify it is enough, then subtract. If two requests interleave, both succeed. Look for the use of database transactions, row-level locks, atomic updates and unique constraints that make the check and the change a single step.

Make it repeatable

Capture abuse cases alongside user stories. For each feature, ask the team "how would we misuse this?" during design, and turn the answers into tests. For critical flows such as payments, refunds, account recovery and privilege changes, an independent secure code review with a focus on abuse cases often finds what internal reviewers cannot see because they are too close to the intended behavior.

Related reading: Manual vs. Automated Secure Code Review: What Each One Finds and A Practical Secure Code Review Checklist for Development Teams.

Key takeaways

  • Logic flaws are code that works as written but can be abused. Scanners generally cannot see them.
  • Write down the rules the business depends on, then look for ways to break them.
  • Validate state transitions and recalculate values on the server instead of trusting the client.
  • Treat any check-then-act sequence as a possible race condition.