How to Find Business Logic Vulnerabilities in Web Apps: Step-by-Step Bug Bounty Guide

In the last two articles, we covered finding secrets and endpoints in JS files, and using those endpoints to hunt for IDOR and Broken Access Control. Both of those are things a scanner can eventually catch if it's good enough.

Business Logic Vulnerabilities are different. There's no payload, no malformed input, no special character that breaks anything. The code runs exactly as it was written — the problem is that the person who wrote it never imagined someone would use the feature this way.

This is why scanners miss these bugs 100% of the time, and why they're some of the highest-paying bugs on programs like HackerOne.

What actually is a Business Logic Vulnerability?

It's a flaw in the workflow or rules of an application, not in its code syntax. Some examples to build intuition:

• A checkout flow that lets you apply a discount coupon more than once
• A password reset flow that doesn't check whose account you're resetting
• A referral system that lets you refer yourself
• An API that lets you downgrade someone else's subscription
• A multi-step form where skipping step 2 and going straight to step 3 still completes the action

None of these involve "hacking" in the traditional sense. You're just using the application in an order or way the developer didn't anticipate.

Step 1: Map out every workflow, not just every endpoint

Forget endpoints for a second. Open the app and list every multi-step process it has:

• Signup — verification — onboarding
• Add to cart — apply coupon — checkout — payment
• Request password reset — receive link — set new password
• Upgrade plan — payment — confirmation
• Invite a team member — they accept — they get access

For each of these, write down what the intended order is. This list is your attack surface — every step is a place where logic can be bypassed.

Step 2: Try skipping steps

Using Burp Suite, intercept each step of a flow and look at what request actually completes the final action. Then try sending that final request directly, without going through the earlier steps.

Normal flow:
POST /checkout/start
POST /checkout/apply-coupon
POST /checkout/confirm-payment   ← this is what actually finalizes the order

Try:
POST /checkout/confirm-payment   (sent directly, skipping the earlier steps)

Normal flow:
POST /checkout/start
POST /checkout/apply-coupon
POST /checkout/confirm-payment   ← this is what actually finalizes the order

Try:
POST /checkout/confirm-payment   (sent directly, skipping the earlier steps)

If the server still processes it, the "steps" were only enforced on the frontend — not on the backend. This is one of the most common business logic flaws out there.

Step 3: Replay and reorder requests

Capture every request in a flow, then try sending them out of order or repeating one of them.

Common things to test:

• Apply a discount coupon twice by replaying the same apply-coupon request
• Submit a form, then go back and resubmit step 1 with different data after step 3 is already done
• Complete payment, then replay the "confirm-payment" request again — does it charge twice, or grant double benefits?

Replay test in Burp Repeater:

1. Capture the "apply-coupon" request
2. Send it once — note the discount
3. Send the exact same request again
4. Check if the discount is applied a second time

Step 4: Manipulate quantities, prices, and negative values

E-commerce and payment flows are full of business logic bugs because they deal with numbers that should always be validated server-side but often aren't.

Try:

quantity: -1
price: 0
price: -50
discount_percent: 150

quantity: -1
price: 0
price: -50
discount_percent: 150

A negative quantity can sometimes make the total price negative meaning the system might owe you money instead of the other way around. A lot of real bug bounty reports have come from exactly this.

Step 5: Test race conditions

A race condition happens when two requests hit the server at nearly the same time and the server doesn't lock the resource properly in between — so both requests get processed as if the other never happened.

Classic example: redeeming a gift card or coupon code that should only work once.

Using Burp Suite's "Send group in parallel" feature (Repeater):

1. Capture the "redeem coupon" request
2. Duplicate it into a group of 5–10 identical requests
3. Send them all at the exact same time
4. Check if the coupon got applied/redeemed more than once

If it does, that's a race condition and it can apply to anything with a "use once" limit: referral bonuses, free trial activations, voting systems, limited-stock purchases.

Step 6: Test for logic flaws in access based on state, not just role

This is different from Broken Access Control. Here, the role is correct (you're allowed to be in this flow), but the state is wrong.

Examples to test:

• Can you access a "post-payment" page without actually having paid?
• Can you view an order's "confirmed" status page for an order that's still "pending"?
• Can you access step 3 of onboarding before completing step 1?

GET /order/1234/confirmation

GET /order/1234/confirmation

Try this directly for an order you know is still pending, or even for an order that doesn't belong to you but is in the right state.

Step 7: Abuse referral, reward, and loyalty systems

These systems are a goldmine because they often reward an action (sign up, invite, purchase) without properly checking who performed it or how many times.

Things worth testing:

• Can you refer yourself using a second email you control?
• Can you create multiple accounts to repeatedly claim a "first purchase" discount?
• Can you invite the same person twice and get credited twice?
• Does the reward get granted before or after the referred action is actually verified?

Step 8: Think about what the feature is for, not what it does

This is the real skill behind finding business logic bugs — less about tools, more about mindset. For every feature, ask:

What is this feature trying to prevent, and is there any path that avoids that check entirely?

A "forgot password" feature is trying to prevent someone else from resetting your password. So — does it check that the reset link's token actually belongs to the account being reset, or just that a valid token was used?

A "cancel subscription" feature is trying to let you stop paying. So — can you cancel someone else's subscription if you know their user ID, even if you can't see their other data?

Writing these questions down for every feature you test is slower than running a scanner, but it's exactly why these bugs are still being found in 2026 on applications that have been pentested dozens of times.

Reporting tips for business logic bugs

These bugs are harder for triagers to validate than a simple XSS, so make the report easy to follow:

• Explain the intended behavior first, in one line
• Then explain the actual behavior your exploit causes
• Give exact step-by-step reproduction — these reports live or die on reproducibility
• Explain real-world impact in business terms (lost revenue, free access, bypassed limits) — this is what gets these bugs rated higher

Final Thoughts

Business logic bugs reward patience and curiosity more than tooling. You don't need an expensive scanner subscription — you need to actually use the application like a real user, then ask "what if I did this differently?" at every single step.

Combine this with the JS recon and IDOR techniques from the last two articles, and you'll have a complete methodology that covers almost every category of bug most hunters skip past.

If you found this article helpful, don't forget to clap and follow for more bug bounty write-ups.

If this guide helped you, consider buying me a coffee ☕ — it keeps me motivated to dig up and write more bugs like this. Buy me a coffee

Monika Hi, I'm Monika ✨I break down real-world bug bounty reports into simple, practical write-ups.If my articles help you…