Business Logic Flaws That Pay More Than SQLi — And How to Find Them

The "Promise Test": a simple way to find bugs that no scanner can see, with real cases, real payouts (small ones too), and one honest warning most articles skip.

In one real case shared on HackerOne's blog, a researcher was offered a $20,000 fee discount on a Stripe account. The discount was meant to work one time.

He used it 30 times. 😮

That covered about $600,000 in fee-free payments. There was no SQL. No database dump. No scary payload. The app simply forgot to protect one rule, "one use only", at the exact moment it mattered. Stripe paid a $5,000 bounty and fixed it.

That bug has a name: a business logic flaw. And here is the strange part. The tools most hunters run first cannot see it.

If you ever felt that every easy bug is already taken, this article is for you. It works for beginners and for advanced hunters. I use simple words, short steps, and real public cases. Every number comes from a source I link to. When I could not find data, I tell you.

Let's go. 🚀

🧩 What is a business logic flaw? (in plain words)

Think of a cinema. It has strong doors and a guard. But the ticket machine lets you type a negative price, and it pays you. The doors are fine. The guard is fine. The rule is broken.

That is a business logic flaw. The app does exactly what the code says. But the code does not match what the business meant.

PortSwigger (the team behind Burp Suite) explains the cause well. Developers make wrong guesses about how people will use the app. They guess that users only use the website, so they trust checks done in the browser. They guess that users will do step 1, then step 2, then step 3, in order. Real users, and attackers, do not follow the guess.

Why scanners cannot see it

A scanner looks for known bad patterns, like a quote mark that breaks a database query. A logic bug has no bad pattern. You are logged in. Your data is valid. Every request looks polite. Only a person who understands the business can say, "Wait, this result is wrong."

The OWASP Testing Guide says the same thing in its own way. Tools cannot tell if a workflow is being skipped or misused. The tester has to use judgment and keep asking "what if?"

This is good news for you. It means a human brain still has an edge. 🧠

🤔 Do logic bugs really pay more than SQLi? The honest answer

The title of this article is a promise, so let me keep it honest. Here is what the public data shows.

What the data supports:

• SQLi is falling in the rankings. HackerOne's 2020 top-10 report ranked SQL injection #7, down from #5 the year before, and said it was dropping year over year. The OWASP Top 10:2025 moved Injection down to #5 (it was #3 in 2021). That list uses test data from over 2.8 million applications.
• Real SQLi is still rated top priority. Bugcrowd's pricing guide lists "SQL injection with significant impact" as P1, the highest level. So please do not skip SQLi. Just know it is rarer now.
• Logic flaws are rising in value. HackerOne's January 2026 post on researcher signals says architecture and logic flaws are increasing in value and tend to earn stronger payouts. It also says access control and IDOR findings are getting more common.

What I could not find: a public report that compares the average payout of business logic bugs with SQLi. Some articles online show neat tables like "$5,000 for SQLi vs $25,000 for price tricks". Treat those as guesses unless they link to real data. I will not invent one for you.

So here is the true version of the title:

Payout follows impact, not the name of the bug.

Bugcrowd explains the process clearly. Their engineers first rate the technical impact. Then the customer reviews the business impact, and that review can change the final priority. A logic bug that moves money, takes over accounts, or breaks trust has big business impact. An SQL injection on a dead page with no data has almost none.

A real price ladder (from public cases)

These are all logic-style bugs. Look at how far apart the prices are:

• $100 (shared by two researchers): Dell's payment API accepted an amount changed by the client, per the researchers' own writeup. It was first triaged P2 and ended at P4.
• $200 and $216: single-use coupons that could be redeemed more than once (Instacart and Dropbox), from a community list of disclosed race condition reports.
• $1,500: a gift card that could be redeemed many times (Reverb), from the same list.
• $5,000: the Stripe discount case from the start of this article (HackerOne blog).
• $15,000: Facebook's password reset code on beta sites, which I explain below (The Hacker News).

The list amounts come from a community collection, so open the report pages for the latest details before you quote them.

The lesson: same bug family, very different prices. What decides the price is what an attacker could do next, and how clearly you show it.

🧪 The Promise Test: six questions that find logic bugs

Forget bug names for a minute. Every feature makes a promise.

"One coupon per person." "Only the owner can see this." "You pay before it ships." "This link expires in an hour."

A logic bug is a broken promise. To find one, write down the promise, then ask six questions. They all start with a simple word.

1️⃣ WHO can do this?

The promise: only the right person can do this action.

How it breaks: a normal user reaches an admin action. Or an app checks who you are when you log in, then stops checking later. PortSwigger lists this as a wrong guess: developers assume a trusted user will always stay trustworthy.

Ask yourself: if I change the account, the role, or the ID, or call the action from another place, does the app still check who I am?

2️⃣ WHICH ORDER?

The promise: step 3 only happens after step 1 and step 2.

How it breaks: the server checks that you are logged in, but not that you finished the earlier steps. PortSwigger gives a clear example: skipping the verification step in a two-factor login.

Ask yourself: which step does the server really check? The step I am on, or only that I have a session?

3️⃣ HOW MANY TIMES?

The promise: one-time things happen one time.

Where to look: coupons, gift cards, free trials, referral bonuses, votes, and discounts offered by support. The Stripe discount lives here.

How it breaks: the action works twice. Or it works twice at the same moment (more on that soon).

Ask yourself: what stops me from doing this again, and is that "stop" strong when requests arrive together?

4️⃣ HOW MUCH?

The promise: the server decides the price, the amount, and the limit.

How it breaks: the browser sends the price, and the server believes it (the Dell case). Or the app forgets that numbers can be negative. PortSwigger shows a transfer with a negative amount that runs in reverse. Intigriti describes a currency code taken from user input, so changing one currency to another lowers the price.

Ask yourself: does the server recalculate every number, or does it trust the number it received?

5️⃣ HOW LONG, or WHEN?

The promise: things expire, and waiting has a cost.

How it breaks: links, tokens, or sessions that live too long. The OWASP testing guide also lists two classic ones. In the first, someone holds items in their cart to block other buyers, then buys them cheaper. In the second, someone earns loyalty points, cancels the purchase, and keeps the points.

Ask yourself: what happens if I wait, or leave and come back?

6️⃣ WHAT STATE?

The promise: an order is paid, shipped, cancelled, or refunded, and it only moves in sensible ways.

How it breaks: Intigriti lists duplicate refunds as a real-world pattern: the system checks that the order exists, but not whether it was already refunded. Another pattern is extra fields in a request that quietly overwrite protected fields, like a role.

Ask yourself: can this object reach a state it should never reach, or reach one state twice?

Six questions: Who? Which order? How many times? How much? How long? What state? Put them on a sticky note. 📝

🆕 Two free checklists most hunters have never opened

You do not need to invent your own list. Two free OWASP lists fit this topic perfectly, and many hunters have not seen them.

OWASP Top 10 for Business Logic Abuse

This is a new incubator project (first release May 30, 2025, second release August 2, 2025). It names ten patterns:

• BLA1, Action Limit Overrun: single-use checks that fail under concurrent requests.
• BLA2, Concurrent Workflow Order Bypass: the last step runs before the earlier steps finish.
• BLA3, Object State Manipulation: unfiltered input overwrites protected fields.
• BLA4, Malicious Logic Loop: weak exit checks let someone trigger heavy hidden work.
• BLA5, Artifact Lifetime Exploitation: tokens or sessions stay valid too long.
• BLA6, Missing Transition Validation: steps can be skipped in a multi-step flow.
• BLA7, Resource Quota Violation: missing limits let one user drain shared resources.
• BLA8, Internal State Disclosure: messages, codes, or timing leak what is happening inside.
• BLA9, Broken Access Control: weak role and permission checks.
• BLA10, Shadow Function Abuse: hidden features, internal APIs, or test tools left unprotected.

See how they match the six questions? That is not an accident. Good checklists end up in the same place.

OWASP API Security Top 10, API6:2023

API6, Unrestricted Access to Sensitive Business Flows, covers bugs where nothing is "hacked" in the technical sense. Someone just automates a normal feature until it hurts the business. OWASP gives three scenarios. A bot buys most of a limited product on launch day and resells it. A person books most seats on a flight and cancels them close to departure. A script farms referral credit for free rides.

Not every program wants this kind of finding, so always check the scope. But it shows how wide "logic" really is.

🚪 The Two Doors rule

Here is a pattern that is easy to remember and easy to test. Many apps protect a rule at the front door and forget the side door.

The famous example: in 2016, researcher Anand Prakash found that Facebook's password reset used a 6-digit code. The main site stopped repeated wrong guesses after about a dozen tries. But the beta versions of the site did not have that limit. Facebook fixed it the day after the report, and paid $15,000.

The promise was "only the owner can know the code". It was protected at one door and open at another.

Doors to look for

• The website and the mobile app API.
• Old API versions (v1, v2) next to new ones.
• Beta or alternate versions of the site, if they are in scope.
• Import, export, and bulk features.
• Support, admin, or partner tools.
• A link in an email versus a button inside the app.

Intigriti shares a nice example. An email field blocked bad input at sign-up, but a separate preferences portal that synced changes did not. Same field, two doors, two different rules.

The OWASP list calls the extreme version Shadow Function Abuse: hidden features nobody protected because nobody remembered them.

The rule: pick one promise, count the doors, and test every door. Stay inside the program scope. 🎯

⏱️ The invisible gap: why "check, then act" breaks

This is the most powerful idea in this article, and it is simple.

Imagine a joint bank account with $100. You and a friend stand at two different ATMs. You both press "withdraw $100" at the same moment. Both machines check the balance first. Both see $100. Both pay out. The bank just lost $100.

The mistake was not the money. The mistake was the gap between "check the balance" and "reduce the balance". In that tiny gap, a second request slipped in.

PortSwigger calls this a race condition, and the "one use only" version is called a limit overrun. They also teach that every request moves the app through tiny hidden steps (they call them sub-states) that last about a millisecond. If a second request touches the same record in that moment, the app can end up in a state nobody planned.

A real case: the Starbucks gift card

In 2015, researcher Egor Homakov wrote about a gift card balance transfer at Starbucks. The app checked the balance in one step and reduced it in another. Two transfers sent at nearly the same moment could both pass the check. In his tests he moved $1 twice from a card holding $5, and later confirmed in a store that the extra value was real.

Two things in his story matter just as much as the bug:

• He first emailed the security team on March 23. He got a reply on April 29. He says the bug was fixed about ten days after he finally reached the right people.
• He does not mention any reward. He says a Starbucks representative called him and talked about fraud instead of thanking him.

I tell you this on purpose. We will come back to it in the safety section.

Predict, Probe, Prove

PortSwigger gives a calm three-step way to think about races in its race conditions guide:

1. Predict. Most endpoints are not worth testing. Pick the ones where two requests would touch the same record: coupons, gift cards, transfers, invites, credits.
2. Probe. First send the requests one by one and learn what normal looks like. Then compare with sending them together. Any difference is a clue.
3. Prove. Cut it down to the smallest set of requests, reproduce it, and understand why it happens. Then you have a real finding and not luck.

If you are curious about the timing side, PortSwigger's research explains how a group of requests can arrive at the server together. Burp Repeater even has a "send group in parallel" option. Race bugs can also be random. The YesWeHack race condition guide notes you may need several tries.

Stay careful: use your own test account, tiny amounts, and stop the moment you see the extra effect once. Never repeat it to collect money. Some programs also ban automated or heavy testing, so read the policy first.

🔍 The 20-minute Rulebook method

Here is a simple routine you can run on any in-scope target.

1. Be a normal user first (5 minutes). YesWeHack's top business logic (CWE-840) hunter for 2024 shared a tip in a YesWeHack post. Use the app like a normal user to learn how it works. Then look for ways around limits that have business impact.
2. Write the rulebook (5 minutes). List ten promises in plain words. The OWASP guide says the same: list the business rules and limits, then check whether the app really enforces them.
3. Follow the movement (5 minutes). Where does money, ownership, or access move from A to B? Look at invite, transfer, merge, refund, gift, referral, trial, upgrade, and change-email features. The Stripe discount, the Starbucks transfer, and the Facebook reset all sit in this group.
4. Run the six questions (5 minutes). Pick one flow and ask Who, Which order, How many times, How much, How long, What state.
5. Compare with normal. Always know what "normal" looks like before you call something strange.
6. Ask "so what?" More on this in the next section.
7. Stop at proof. Show the problem once, safely. Do not profit from it.

Think like the finance team

The YesWeHack tip includes a nice example. A booking site sets prices by demand. If someone could start many bookings without paying, prices would rise for real customers, and the company would lose sales. No data is stolen, yet the business is hurt. Ask yourself, "If this happened a million times, what would the company lose?"

📝 How to report so it actually pays

Most articles stop at "how to find it". But the report decides your payout, so this part matters.

Show the impact in plain words

Remember: after the technical rating, the customer reviews business impact. Help them. Say clearly what an attacker could do, in money, accounts, or trust. In the Stripe case, the researcher worked out the cost to Stripe: about 3% of each discount, so around $600 each time a $20,000 discount was abused. The bug was rated Medium, and it still paid $5,000. A small number, clearly explained, still counted.

Not every odd behavior is a bug

Intigriti gives a useful filter: ask whether the issue hurts confidentiality, integrity, or availability. Their examples of things that do not count include editing your own data in your own account with a proxy, and a fitness app calculating calories badly. Odd is not the same as dangerous.

Severity can move

The Dell report started at P2 and ended at P4 with a $100 reward, according to the researchers. Their writeup does not tell the full story of why. But it is a good reminder that severity can change during triage. Put your best impact explanation in the first report, not in a later comment.

Retest the fix

In the Stripe case, the first fix still allowed multiple redemptions. The researcher showed it, and the second fix closed the hole. If the program asks you to confirm a fix, test the same idea again, and test the neighbors too. This is also a good habit for you as a hunter.

A simple report template

• Title: [Feature] lets [who] break [rule]
• The promise: what the app is supposed to guarantee
• What I did: 3 to 5 short steps, with a test account
• What happened: what the app did instead
• Why it matters: the realistic worst case, in money, accounts, or trust (described, not performed)
• Fix idea: one or two lines
• Proof: screenshots or a short video

🔧 How developers fix these (and why it helps your report)

If you can suggest a fix, your report looks more professional. The fixes are simple ideas:

• The server decides. Recalculate prices, totals, and discounts on the server at every step. Never trust the browser.
• One rulebook for steps. The server should know which step comes next and refuse anything else.
• Check and act in one move. Use database transactions and locks so there is no gap, plus uniqueness rules as a second shield (PortSwigger recommends this).
• Make repeats safe. Operations like payments should be safe to repeat without double effects (this is called idempotency).
• Protect sensitive flows. OWASP API6 suggests limits and bot checks on flows that can hurt the business if abused.
• Guard every door the same way. If a rule exists on the website, it must exist on the app, the old API, and the admin tool.

✅ The cheat sheet

• A logic bug is a broken promise, not a broken lock.
• Write the promises first. Then ask: Who? Which order? How many times? How much? How long? What state?
• Count the doors. Test the side door, not only the front door.
• Look for the gap between "check" and "act".
• Follow money, ownership, and access as they move.
• Show business impact in plain words.
• Retest fixes.
• Stay in scope, use test accounts, stop at proof.

#BugBounty #BusinessLogic #BusinessLogicFlaws #BugBountyTips #CyberSecurity #EthicalHacking #InfoSec #WebSecurity #HackerOne #AppSec