Englishবাংলা
SubscribeWrite
Latest
Binary search: patterns, templates and common pitfallsDocker's $250 Cloud Sandboxes credit: what it covers and what it does notTwo pointers and sliding window: patterns with examplesArrays and hash maps: the interview patterns you must knowBig-O notation explained: time and space complexity for interviewsSoftware testing basics: the test pyramid and what to testClean code and code review habits that make you a better developerREST API design best practices: URLs, status codes and errors

Business logic bugs: the findings scanners never report

Logic flaws hide in the rules of the app, not in the code patterns scanners look for. Here is how to map a workflow, where the money-moving mistakes usually sit, and how to write a report a triager accepts.

••3 min read
A checkout flow where the path skips the payment step and goes straight to confirmed

Scanners are good at patterns: a reflected parameter, a missing header, a known version. They are blind to rules. Nothing in an HTTP response tells a tool that a refund should never exceed the payment, or that step three of a checkout must come after step two. That blind spot is why logic bugs are some of the least duplicated findings in bug bounty programs.

Think in rules, not payloads

Every feature encodes assumptions. Your job is to list them and then break them one at a time:

  • "Users reach the confirmation page only after paying."
  • "A coupon is used once per account."
  • "Quantity is a positive whole number."
  • "Only the owner can change this order."
  • "The price the server charges is the price it showed."

Write these down before you send a single request. The list is your test plan.

Map the workflow first

Pick one flow that matters to the business, such as sign-up, checkout, refunds, invitations or plan upgrades, and walk through it normally with a proxy running. For each step, note:

  1. the request that moves you forward;
  2. which values come from the client (prices, IDs, step names, flags);
  3. what the server checks, and what it seems to trust.

With the map in front of you, the interesting questions appear on their own.

Where logic bugs usually live

Skipped steps. Send the request for the last step without the ones before it. Many apps check the order in the browser and nowhere else.

Client-controlled values. If the request carries price, discount, role, plan or isVerified, change it. A server that recalculates everything is fine; one that stores what it receives is a finding.

Numbers at the edges. Try zero, negative values, decimals, very large numbers and different currencies. A quantity of -1 that turns a charge into a credit is a classic.

Limits that are counted too late. Coupons, free trials, referral rewards, withdrawal limits. Send the same request many times at once:

# 20 parallel attempts to redeem a single-use coupon (test accounts only)
seq 20 | xargs -P 20 -I{} curl -s -o /dev/null -w "%{http_code}\n" \
  -b "session=$TEST_SESSION" -d "code=WELCOME10" https://target.example/api/redeem

If more than one attempt succeeds, the check and the update are not atomic: a race condition.

State changes after the fact. Cancel an order after it ships, downgrade a plan but keep the features, leave a team but keep the invite link, change the email on an account and see whether old sessions and reset links still work.

Mixed contexts. Apply a coupon from one region in another, use a mobile-only API from the web, combine two promotions that were never meant to stack.

Stay inside the rules of the program

Logic testing touches real money and real data more often than other bug classes. Use your own test accounts, small amounts, and the program's sandbox or test cards where they exist. Never complete an order you cannot cancel, and stop as soon as you have proof. Read the scope page: some programs exclude rate limiting or promotions entirely.

Write the report for a busy triager

A logic bug only lands if the reader understands the rule you broke. Structure it like this:

  • The rule: "A single-use coupon can be redeemed once per account."
  • What happens instead: "Sending the redeem request 20 times in parallel applies it 6 times."
  • Steps to reproduce: numbered, with the exact requests and test account names.
  • Impact in business terms: "Any user can stack the 10% welcome discount until the order is free."
  • Evidence: the responses, and the order total before and after.

Leave out theory and severity arguments. A clear rule, a clear break and a clear cost do the persuading for you.

A short checklist

  • List the assumptions of one important workflow
  • Replay the last step without the earlier ones
  • Change every value the client sends that the server should own
  • Try zero, negative and huge numbers
  • Race every "once only" action
  • Change state after the fact and see what survives

Tools find the bugs everyone else finds too. Rules are where the quiet, high-impact findings are, and reading them carefully is a skill no scanner has.

Keep reading