Business Logic Flaws: A Bug Hunter’s Handbook

Business logic flaws, also known as application logic flaws, occur when an application’s legitimate functionality is misused in ways the developers never intended. Unlike typical code bugs like XSS or SQLi, these are design-level weaknesses, not implementation errors. As one recent overview puts it, these are flaws where the application works technically as intended, but not as per the business rules.

In other words, the code might not be insecure in the usual sense, but the design allows users to do things the business never intended. Unlike code-related bugs, logic flaws rely on a creative understanding of the app’s workflows and assumptions. For example, imagine a checkout form that allows users to modify price or quantity fields directly on the client side. If the backend doesn’t revalidate those values, an attacker could quietly alter the final cost, bypassing discounts, limits, or billing checks.

One famous case involved Stripe, where a researcher exploited a race condition to redeem a $20,000 discount 30 times in parallel, gifting himself over $600,000 in credits [1]. The bug wasn’t in the code’s syntax, but in the absence of logical locking. Stripe paid a $5,000 bounty and quickly patched the issue. It stems from wrong assumptions about user behavior or missing checks in workflows. Left unpatched, such flaws can cost companies money, reputation, and regulatory fines. Because logic flaws depend on the intended flow of an app, they require human insight to find. As such, they often evade automated scanners and are prized by bounty programs.

According to HackerOne, 10% of all vulnerabilities reported to the cryptocurrency and blockchain industry are logical bugs, and 45% of their total bounty payout dollars go to logic bugs [2]. That’s nearly half the budget going toward a class of bugs that most tools can’t detect. In 2025, with surface-level bugs largely patched, more hunters are focusing on logic flaws to make an impact.

Common Types of Logic Flaws

Real-world logic bugs fall into several broad categories. Here are some frequent patterns seen in bug bounties:

• Client-Side Trust / Tampering: The app trusts data such as price, role, or other parameters from the browser without re-validating on the server. An attacker simply uses a proxy to modify form values and bypasses rules. These issues “give clients too much control” and let hackers skip checks. Example: In one finding, a hunter was able to get admin access by inserting admin into the userDetails field. [3]
• Insufficient Data Validation: Unexpected inputs break workflows. For example, allowing negative or extremely large numbers can reverse logic. If a transfer form accepts a negative amount, the app may send money to you instead of from you. Negative quantity or huge discount values can similarly cheat calculations. These cases often slip through since client-side checks can be bypassed.
• Workflow Bypass (Assumption Failures): The app assumes users follow steps in order. If you skip step 2 or repeat steps out of sequence, unexpected states occur. Attackers skip steps, remove parameters, or trigger functions in odd sequences to confuse the system. Failure to enforce the intended sequence can let users gain privileges or access data they shouldn’t.
• Access Control / ID Issues: Logic flaws often show up as authentication/authorization bypasses. For instance, an IDOR (Insecure Direct Object Reference) where attackers supply a different user’s ID and the server serves another user’s data. Strictly speaking this is a flawed access-control logic, not just a missing check.
• Race Conditions: Timing issues can subvert logic. The Stripe discount example above was a race condition: rapid, parallel requests let one redemption slip through additional fixes. Any feature that should only happen “once” (single-use coupon, one-time transaction) is a candidate for race-based abuse.
• Domain-Specific Flaws: These depend on business rules unique to the app. E.g., loyalty points or discounts might not re-validate when cart contents change, letting people abuse promotions. A classic case: apply discount, then remove items, original discount threshold no longer met, but system never checks again. Every industry has its own quirks, so logic bugs are often bespoke but follow similar themes.
• Other Patterns: ID enumeration, payment logic flaws , and broken rate-limit logic are also logic issues. In short, if it’s about how the app’s processes are supposed to work, there’s potential for logic error.

The Hunting Process

1. Understand the workflow. Before testing, use the application like a normal user and map out every step of the user and admin flows. Create a simple diagram or bullet list of the normal flow like how I do it:

User adds item to cart → selects shipping → pays via Stripe → order confirmed

Take notes in a way that you understand the application logic later you visit the note again.

Identify all business rules like:

• Limits: The Application assigns one free coupon per user
• subscriptions: Free delivery is only available to premium users
• Promotions: After ordering 10 products, a user gets the top user role, etc

This stage might involve reading documentation, clicking through the UI, or inspecting a sitemap. Once you understand the application completely, you can start playing with the application and answer your What If?’s

2. Explore the API and UI in tandem. Many logic checks happen behind the scenes. Use Burp Suite or a similar proxy to intercept requests as you click through the UI. Note every API endpoint and parameter. Look for endpoints accessible in the frontend vs those hidden or disabled. It often helps to browse the app’s public API documentation or decompile its mobile app for hidden calls. Then test hitting those endpoints manually. For example, if a “Team plan” feature is hidden in the UI for free users, try accessing it directly via a guessed URL or API path.

3. Tamper and test edge cases. With Burp Repeater or Postman, start modifying parameters and workflows. Key tactics include:

• Parameter tampering: Change IDs, flags, prices, etc. For instance, modify a product’s price from $100 to $50 or even -100 to test negative pricing. Alter boolean fields in JSON, such as changing "isAdmin":false to true. Remove or reorder parameters in a multi-step form.
• Authentication and roles: Try accessing admin or team features with a normal user by modifying cookies, tokens, or JWT payloads. Look for parameters like role=, user_id=, or session cookies that may grant extra privileges when changed.
• Subscription and premium gating: Test premium features. For example, after a free user cancels a paid upgrade, check if they still have access (sometimes refunds aren’t fully enforced). Force-browse premium URLs or API endpoints.
• Concurrency: Use Turbo Intruder or your own script to send many requests at once. Race-test operations like coupon redemption, account creation, or refunds. See if parallel requests slip through checks. Example: Stripe’s “accept coupon” call was hit 30 times in parallel, redeeming a $20k discount 30 times.
• Sequential workflows: Try skipping steps or repeating steps out of order. For example, see if you can jump straight to the post-login page without logging in, or hit a confirm order endpoint twice. Observe how the server responds when expected tokens or states are missing.

Always monitor the raw requests and responses. If the app returns an unusual success or status code, that might indicate a logic hole. Tools like Burp’s Autorize extension can automate checking access controls, but logic flaws often need more context-specific scripts. For concurrency, use Turbo Intruder for high-speed requests. For pattern fuzzing, write a small Python script or use Burp Intruder to brute-force critical fields like trying price=0.0 vs price=0, or iterating boolean flags.

Case Studies: High-Profile Logic Flaws

Stripe: Unlimited Discount Race-Condition

• Summary: A researcher at HackerOne found that Stripe’s fee-discount coupons could be redeemed multiple times due to a race condition. In this case, Stripe offered a $20,000 transaction fee credit to the tester. The tester clicked “Accept” on the Stripe dashboard once (to get the coupon), then intercepted the underlying API call and re-sent it dozens of times in parallel using Turbo Intruder. Each call applied the $20k discount anew.
• Impact: Each time the coupon was reused, Stripe effectively lost 3% in transaction fees. By abusing the $20k coupon 30 times, the tester gave himself $600,000 in fee-free transactions. At scale, this could have cost Stripe ~$600 per redemption. The bug earned a $5,000 bounty.
• Lesson: This shows how concurrency can violate a business rule (a coupon should only be used once). The fix required enforcing a lock or server-side flag so that the discount cannot be reapplied after the first use. Testing tip: Always try making critical state-changing requests in parallel to check for race conditions. [1]

GitHub: Unicode Password Reset Flaw

• Summary: In late 2019, a security researcher discovered that GitHub’s password-reset logic mishandled certain Unicode characters. Specifically, if a user’s email contained the Turkish dotless ‘ı’ (e.g. jıll@example.com), GitHub’s server code would lowercase (toLowerCase) that character and map it to a plain ‘i’ (so jıll became jill). An attacker could register an account or initiate a reset using jıll@example.com. The system would find the valid account jill@example.com after case-folding, but still send the reset email to the attacker’s address (jıll@example.com). The attacker thus received a reset link meant for another user.
• Impact: If the victim did not have two-factor auth enabled, the attacker could set a new password and take over the account. This business logic flaw was fixed by GitHub after disclosure.
• Lesson: Input normalization (like case-folding) can create equivalence collisions. Bug hunters should test with Unicode characters in authentication or identity fields. For example, try special or accented characters in emails and user names to see if they merge or collide after server-side processing. (Visualization: a diagram of the reset flow could highlight how the email parameter is transformed and misdirects the reset.) [4]

Subscription Bypass: Direct API Abuse

• Summary: Several bounty reports have shown that web apps sometimes hide premium features on the UI but don’t enforce them on the back end. In one case on a platform (pseudonym “ExamenTry”), free-tier users could bypass Team-tier restrictions by calling internal APIs directly. One researcher manipulated the organization settings endpoint (/api/0/organizations/<org>), setting a JSON flag "codecovAccess": true. This granted him access to the Team-only “code coverage insights” feature without paying [5]. In another case on the same platform, the researcher used a crafted URL or API call (the Splunk plugin endpoint) to enable a paid “data forwarding” plugin for free accounts. [6]
• Impact: In each case, the attacker unlocked a feature reserved for paying customers. The bounties were moderate ($350–$469), but the takeaway is huge: any feature gated by plan can be targeted via API.
• Lesson: Don’t trust the UI alone. Test by capturing normal upgrade or settings-change requests and then sending them manually. Try toggling values or enabling options that the UI normally disables. Check cookies or JSON fields for access flags, and try to modify them. Here, simply setting a flag in a JSON payload bypassed the Team plan requirement. Always enforce plan restrictions on the server, not just in the client.

Insurance Portal: Race-Conditioned Duplicate Accounts

• Summary: On a business-to-business insurance platform, Abhi Sharma found that the member-creation API had a race condition. The app was supposed to prevent creating two employee profiles with the same email and ID. However, that check only ran in the web layer. By capturing the GraphQL “create profile” request and sending it many times in parallel (using Turbo Intruder), the attacker was able to slip several requests through before the first one completed.
• Impact: Multiple profiles were created for the same employee, leading to billing and coverage confusion. The bug earned a $500 bountymedium.com. More importantly, it exposed how critical business constraints (email uniqueness) must be enforced at the database level.
• Lesson: Race conditions can break logic rules. When an action (like signup or coupon redemption) should be one-per-user, test it with concurrent requests. The researcher’s steps were: log in with an attacker account, capture the profile-creation request in Burp, change the payload to reuse a protected email, then push it to Turbo Intruder. Using Turbo Intruder (or any fast HTTP tool) for such tests is crucial. Also, always consider how to lock or check in the database to avoid multiple simultaneous insertions causing logic failures. [7]

Test Ideas & Checklist for Business Logic

Approach logic testing like a detective. Be systematic and ask “What if I do X instead of the normal flow?” Here’s a checklist of common ideas and techniques (many inspired by real bounty write-ups) to try on any target:

Get Gr3yG05T’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Parameter and Input Anomalies:

• Tamper with numeric fields. Change prices, quantities, or points to negative (-100) or fractional values (0.5 * price)
• Try zero, empty, null values, or extremely large numbers. Observe currency or type conversions.
• Test Boolean and flag fields. If a JSON or cookie has "premium":false, flip it to true and retry the request
• Mass-assign or HTTP parameter-pollute: send multiple values for the same field (e.g. coupon[]=A&coupon[]=B) and see how the server handles it

Access Control and Role Abuse:

• Change IDs in URLs or payloads. If you see user_id=1001, try 1002, 1003, etc. Can you view or modify another user’s data?
• If you have a “normal user” session, try accessing an admin URL (e.g. /admin/settings) or injecting an admin token. If there’s a numeric or name-based role, try escalating it.
• Test multiple authentication factors or steps. For example, if a password reset or 2FA flow exists, try skipping or repeating steps out of sequence

Workflow and State:

• Skip steps: Attempt to jump ahead or call APIs before earlier steps are complete. For instance, submit a purchase order request without setting shipping.
• Retry steps: Perform a multi-stage operation twice. Submit the final “confirmation” twice or go back and forth between steps with Repeater.
• Omit parameters: Remove a required form field or header. Sometimes removing a parameter entirely can reveal an alternate code path

Business-Specific Scenarios:

• Coupons/Discounts: Apply the same promo code multiple times to see if it can be reused. Use concurrent requests on the redeem action (coupon race). Try adding multiple codes via parameter pollution, even if the UI allows only one.
• Refunds and Refund Abuse: Buy a paid feature, cancel it, and check if you still have access. Trigger multiple refund/cancel requests (race them) to see if you get extra money back. Try cross-currency purchases/refunds (USD vs. EUR) to exploit exchange rate arbitrage
• Shopping Cart: Add negative-quantity items or exceed stock quantity. Combine items so total price calculations break (e.g. one item with price +5, another -5).
• Permissions/ACLS: Look at cookies or tokens for permission bits. Many apps encode roles or feature access in a cookie or JSON (session ID, JWT claims). Toggling those might reveal hidden sections. Use Burp Intruder to brute-force such flags (change bits from 0 to 1, Y to N, etc.).
• Comment/Forum functions: If there’s a “one comment per user” rule, try posting fast concurrent comments to see if you can post multiples. See if privileged actions (like a verified-user badge) can be faked by altering your request.

Race Conditions:

• Key operations like account creation, transfer of points, or checkout should be tested concurrently. Use Burp’s Turbo Intruder: capture a legitimate request, then flood the target with 10s or 100s of parallel copies. Observe if the server ever drops or incorrectly processes duplicates. For each test, try increasing the thread count until the backend shows inconsistent behavior.
• Pay special attention to operations that should be one-time-only (creating a profile, granting a reward, redeeming a coupon).

Tools to Have On Hand:

• Burp Suite (Free & Pro): proxy/intercept, Repeater for manual tweaks, Intruder for parameter fuzzing. Use the Match & Replace feature to automatically flip values (e.g. toggle true/false in every request).
• Turbo Intruder: A burp extension, essential for high-speed or concurrent requests that Burp’s Intruder can’t handle.
• Breach-type plugins: (e.g. Autorize, Auth Matrix) to automate access control checks.
• Scripting: a quick Python or Go script to manipulate requests in bulk can help, especially for logic checks.
• Session/Cookie tampering tools: e.g. CookieDoughnut or manual hex editing to spot weakly-signed cookies.
• Workflow visualization: drawing tools (like diagrams.net) to sketch user flows and find where logic might break. (Suggested Visual: a workflow diagram with branches for “what if user cancels now” or “if two requests race” to plan tests.)

This checklist is by no means exhaustive, but covers many common patterns. Always think of the intended business rule behind a feature, and then try to violate it with creative input or timing. Use automated tools to explore, but manual reasoning is crucial. When you find a weird server response, pause and map it to the business flow: that’s your hint you might be onto a logic flaw.

Further Resources

PortSwigger Web Security Academy: Business Logic Vulnerabilities. Interactive labs (e.g. “Excessive trust in client-side controls”, “High-level logic flaw”) that walk through real examples. Great for hands-on practice.

Pentester Land: Pentester Land stores various bug bounty write-ups, including tons of business logic write-ups, which are crucial for understanding the bug.

OWASP WSTG: Business Logic Testing (v4.2), The official Web Security Testing Guide section provides methodology and test cases for logic flaws

HackerOne Blog & Hacktivity: The “Unlimited Discount” post is a must-read case study. Also browse Hacktivity for logic flaw disclosures.

Hack The Box Academy: Parameter Logic Bugs, A practical module with code review and labs covering validation logic, unexpected input, and null-safety bugs.

Legit Security Blog: “Business Logic Vulnerabilities: Examples and Prevention” is a detailed guide with definitions, examples, and best practices.

Bright Security Blog: “Business Logic Vulnerabilities: Busting the Automation Myth”, explains why logic bugs are hard and lists common patterns to target.

OWASP Foundation Articles: OWASP frequently discusses logic flaw scenarios on their blog and in their top-10 (e.g. BOLA).

Conclusion and Next Steps

Business logic flaws are among the most challenging and rewarding bugs you can hunt. They force you to think like the designers, question every assumption, and get clever with tools. The reward potential is high precisely because these bugs often have a serious impact and usually only skilled hackers find them.

If you want to master logic hacking, start by studying published case studies, write-ups, and practicing on purpose-built labs. See the PortSwigger Academy labs on logic flaws (client-side trust, unusual input, etc.). Read Hacktivity write-ups and bounty blogs, for example, the Stripe coupon example and GitHub password-reset flaw are detailed on HackerOne and personal blogs. Follow infosec communities (Medium posts, Bugcrowd University, r/bugbounty) where researchers share business logic hunting tips.

In summary, think of logic vulnerabilities as puzzles where the business rules are clues. Keep your mindset broad and skeptical: what if the user’s input is something the dev never expected? The next time you poke at a signup form or payment button, remember: the real exploit might not be a crash or overflow, but a subtle twist in the logic. Think Like A Hacker. Happy hunting!

Hello Im Raduanul Islam Rohan or Gr3y G05T. I didn't add the introduction part up above because it was killing the vibe of this paper. When I started to learn about Business Logic Flaws, there was an absence of a resource like this, so I decided to build something myself. I’m not the most experienced hunter in that category, but I have poured everything I know into this paper. I will try my best to keep this thing updated and add more info as I grow. When I feel confident enough with the standard, I will publish it in a publication. I’m adding an edit log below to keep track. If you wanna contribute or have some query, you can reach me at @gr3yg05t. Together, we hit harder.

Edit Log (BST)

17:23 | 06/07/25 → Published the first draft of the handbook