Business Logic Vulnerabilities: The Bugs Your Scanner Will Never Find 🕵️‍♂️

Why some of the most damaging security flaws have zero payloads, zero malformed input, and zero chance of ever showing up in a scanner report.

Let’s start with a real-world-style scenario instead of a definition. 👇

You’re testing an e-commerce checkout flow. You add a $500 pair of headphones to your cart, intercept the request in Burp Suite, and notice this in the JSON body:

json

{
  "item_id": "8842",
  "price": 500,
  "quantity": 1
}

You change "price": 500 to "price": 1, forward the request, and complete checkout.

It works. You just bought $500 headphones for a dollar. 🎧💸

No SQL injection. No XSS. No malicious payload of any kind. Just a number that the server should never have trusted from the client in the first place. That’s a business logic vulnerability — and it’s exactly the kind of bug that Burp’s automated scanner, SQLMap, and Nikto will sail straight past, because nothing about that request “looks” malicious. It’s just… wrong.

Let’s go through the main categories with examples like this one, so you know exactly what to go looking for. 🔍

1. Price & Parameter Manipulation 💰

The flaw: The server trusts a price, discount, or total sent from the client instead of recalculating it itself.

Example: Same as above — you intercept the checkout request and edit price from 500 to 1. Or you apply a "WELCOME10" coupon code, then replay the same request five times, and the discount stacks each time instead of applying once.

How to test: Intercept every request in a purchase flow in Burp Suite. Try:

• Editing price/quantity/discount fields directly
• Applying the same coupon multiple times
• Setting quantity to -1 (does the total go down instead of up? 👀)

2. Workflow / Step-Skipping 🪜

The flaw: A multi-step process (KYC verification, password reset, loan approval) assumes users will complete steps in order — but the server never actually checks that they did.

Example: A password reset flow looks like:

1. POST /reset/request → sends OTP to email
2. POST /reset/verify-otp → confirms OTP
3. POST /reset/set-password → sets new password

You skip straight to step 3 and call it directly with someone else’s email in the body. If the server doesn’t check that steps 1 and 2 actually happened for that session, you just reset a stranger’s password without ever seeing their OTP. 🔓

How to test: Map the full flow first. Then call each endpoint out of order, skip steps, and reuse old tokens across different sessions.

3. Race Conditions ⚡

The flaw: The app checks a value (“do they have enough balance?”) and then updates it (“subtract the amount”) as two separate steps — with a tiny gap between them.

Example: A gift card has $10 left. You send 20 identical “redeem $10” requests at the exact same moment using Burp’s Turbo Intruder. Because the server checks the balance before each one finishes updating it, ten or more of those requests succeed — you just redeemed $100+ off a $10 card. 🎯

How to test: Use Turbo Intruder or Repeater’s parallel requests on anything that debits a balance, redeems a code, or claims limited stock (flash sale items are a favorite target for this).

4. Negative & Boundary Values 🔢

The flaw: A numeric field accepts values outside what makes real-world sense — negative numbers, zero, decimals, or huge integers.

Example: A “transfer funds” feature lets you send money between your own two wallets. You send amount: -1000 from Wallet A to Wallet B. Instead of failing, the negative subtraction adds $1000 to Wallet A while barely touching Wallet B. 🧮💥

How to test: Throw negative numbers, 0, decimals where integers are expected, and absurdly large values into every quantity, amount, and points field you can find.

5. Role & Permission Logic Gaps 🛂

The flaw: The frontend hides admin buttons from low-privilege users, but the backend never actually checks the role when the action is called directly.

Example: A support agent’s dashboard has no “Delete User” button visible in the UI. But you grab the DELETE /admin/users/{id} request from browsing the app as an admin once, then replay it using the support agent's session token. It works — because the button being hidden was the only protection. 🚪

How to test: Capture every state-changing request while logged in as a high-privilege account, then replay each one using a lower-privileged account’s session token.

6. Rate Limit & Quota Bypass 🚦

The flaw: Limits are enforced based on something the client controls (a header, a cookie, a value in the request body) instead of something only the server controls.

Example: An OTP endpoint blocks you after 5 attempts — based on the X-Device-Id header sent in the request. You change that header value on every request and now you have unlimited OTP guesses. 🔁

How to test: Look at exactly what a rate limit is keyed on. If it’s anything client-supplied, try rotating it.

A Simple Method to Hunt These 🧭

You can’t scan for these — you have to think like the product. A quick loop that works:

1. Walk the flow as a real user first. Note every step and every value that changes (money, status, permissions).
2. Ask, for each step: “what is the server assuming right now — and who actually controls that?”
3. Break the order. Skip steps, repeat steps, replay old tokens.
4. Break the timing. Fire requests in parallel that were meant to happen one at a time.
5. Break the numbers. Negative, zero, decimal, huge.
6. Break the role. Replay privileged actions with an unprivileged session.
7. Write the impact in plain business terms — “an attacker can get unlimited store credit” lands far better in a report than “parameter lacks server-side validation.” 📝

OWASP’s Testing Guide has a dedicated business logic testing section worth using as a checklist baseline — it’s one of the few places that explicitly says automated tools aren’t enough here, and that manual, product-aware testing is required. 📚

Final Thought 💡

A SQL injection gets fixed by sanitizing input. A business logic flaw gets “fixed” the moment someone finally asks: “wait — what happens if a user doesn’t play by the rules I assumed they would?” That question is far easier to ask by hand than to bake into a scanner.

If you’re used to leaning on Burp’s automated scanner, SQLMap, and Nikto to find your bugs for you, business logic testing is the next skill worth building — it’s slower and manual, but it’s also where some of the most impactful, best-paying findings live. 🚀

I write about web application security, VAPT methodology, and real-world vulnerability research. Follow along for more. ✍️