# Business Logic Exploitation

> Exploit flaws in application workflow, authentication bypass, price manipulation, and privilege escalation by abusing intended business logic rather than technical vulnerabilities.

- **URL:** https://hackindex.io/services/web/exploitation/business-logic-exploitation
- **Path:** HTTP/HTTPS > Exploitation
- **Up:** [Exploitation](https://hackindex.io/services/web/exploitation.md)
- **Published:** 2026-09-13
- **Updated:** 2026-09-13

Business logic flaws break application assumptions rather than input validation. These are not injection bugs or misconfigurations. They exist because the developer assumed users would follow the intended workflow, and the server does not enforce that assumption. Every application has unique logic, so these vulnerabilities are specific to the target. Automated scanners do not find them. Manual testing against each application's rules is required. Logic flaws frequently chain with [authentication weaknesses](https://hackindex.io/services/web/vulnerability-discovery/authentication-vulnerability-testing) and [access control gaps](https://hackindex.io/services/web/vulnerability-discovery/access-control-testing), since bypassing workflow steps often means bypassing authorization checks.

Common business logic exploitation techniques covered here:

- Price manipulation through negative quantities, rounding abuse, and discount stacking
- Multi-step process bypass by skipping or reordering required steps
- Client-side control bypass by modifying hidden fields and removing validation
- Insufficient workflow validation on privileged endpoints
- Race conditions in checkout, coupon redemption, and balance transfers

## Price Manipulation

Applications that calculate totals client-side or trust price fields in the request body are vulnerable to direct manipulation. Intercept the checkout request and modify the price, quantity, or discount fields before they reach the server. Test negative quantities first. Many carts multiply price by quantity without checking for negative values, resulting in a credit instead of a charge. Currency rounding is another vector: if the application rounds per-item prices, buying fractional quantities or triggering repeated rounding operations can reduce the total below the expected amount. Discount code stacking works when the application applies each code independently without checking whether a discount was already applied.

```bash
curl -sk -X POST http://$TARGET_IP:$PORT/api/checkout -H 'Content-Type: application/json' -H 'Cookie: session=YOUR_SESSION' -d '{"items":[{"id":1,"price":0.01,"quantity":1}]}'
# {"order_id":4821,"total":0.01,"status":"confirmed"}
```

```bash
curl -sk -X POST http://$TARGET_IP:$PORT/api/cart/update -H 'Content-Type: application/json' -H 'Cookie: session=YOUR_SESSION' -d '{"item_id":1,"quantity":-1}'
# {"cart_total":-49.99,"items":[{"id":1,"name":"Premium Plan","quantity":-1,"subtotal":-49.99}]}
```

A negative total or a total significantly lower than expected confirms the application trusts client-supplied values. Check the response for the actual charged amount. Some applications accept the manipulated request but calculate the real total server-side, so verify by checking the order confirmation or account balance. If the cart accepts negative quantities but the checkout endpoint recalculates, try adding a second item with a large negative quantity to offset the total of the legitimate item.

## Multi-Step Process Bypass

Multi-page forms and wizards often validate each step individually but do not verify that all previous steps were completed before accepting the final submission. If step 3 of 4 is the payment page, submit step 4 directly and check whether the order processes without payment. Capture the final submission request in Burp Suite, note its parameters, then replay it in a fresh session without completing earlier steps. Hidden fields carrying state between steps are common targets. Values like `step=4`, `verified=true`, or HMAC tokens passed between pages may be accepted without validation.

```bash
curl -sk -X POST http://$TARGET_IP:$PORT/api/order/confirm -H 'Content-Type: application/json' -H 'Cookie: session=YOUR_SESSION' -d '{"step":4,"order_id":1337,"payment_verified":true}'
# {"status":"order_confirmed","order_id":1337}
```

```bash
curl -sk -X POST http://$TARGET_IP:$PORT/api/account/upgrade -H 'Content-Type: application/json' -H 'Cookie: session=YOUR_SESSION' -d '{"plan":"enterprise","billing_step":"complete","promo_applied":true}'
# {"account":"enterprise","next_billing":"2027-10-13","amount_due":0}
```

If the server returns a success response without requiring completion of intermediate steps, the workflow validation is broken. Test variations: replay step 2 after step 3, skip step 2 entirely, or submit steps out of order. Some applications track state in the session but accept any step at any time. Others use tokens that expire or rotate per step, which are harder to bypass but still worth testing if the token is predictable or reusable.

## Client-Side Control Bypass

Client-side validation exists for user experience, not security. Any restriction enforced only in the browser can be bypassed by modifying the request directly. Hidden form fields carrying price, role, discount percentage, or account type are the highest-value targets. Disabled or read-only fields in the HTML are still submitted in the form data and may be processed by the backend. Remove `disabled` or `readonly` attributes in DevTools, change the value, and submit. If the form uses JavaScript validation, either disable it or intercept the request after validation but before it leaves the browser.

```bash
curl -sk -X POST http://$TARGET_IP:$PORT/api/register -H 'Content-Type: application/json' -H 'Cookie: session=YOUR_SESSION' -d '{"username":"testuser","password":"password123","role":"admin","discount":100}'
# {"id":52,"username":"testuser","role":"admin","discount":100}
```

If the response reflects the injected `role` or `discount` field, the backend accepts parameters that the form does not expose. This is a mass assignment vulnerability combined with a logic flaw. Verify the role actually grants elevated access by testing an admin endpoint with the new session. For price fields, add parameters that the form does not include: `discount`, `price_override`, `is_staff`, or `coupon_value`. Check the application's JavaScript source for parameter names the frontend sends in other contexts.

> [!NOTE]
> Burp Repeater is the most efficient tool for this type of testing. Capture the original request, send it to Repeater, and modify individual fields while watching the response. This avoids re-filling forms and lets you iterate quickly across different parameter combinations.

## Insufficient Workflow Validation

Applications that rely on UI navigation for access control expose privileged endpoints to anyone who knows or guesses the URL. Admin panels, management dashboards, and internal tools often have endpoints that return data or accept actions without verifying the user's role. Forced browsing through common admin paths is the starting point. Once an admin endpoint is found, test whether a regular user session token is accepted. Method switching is another angle: an endpoint might reject GET requests for unprivileged users but accept POST, PUT, or DELETE with the same session.

```bash
curl -sk http://$TARGET_IP:$PORT/admin/users/export -H 'Cookie: session=REGULAR_USER_SESSION' -o admin_export.csv
```

```bash
curl -sk -X DELETE http://$TARGET_IP:$PORT/api/users/1 -H 'Cookie: session=REGULAR_USER_SESSION'
curl -sk -X POST http://$TARGET_IP:$PORT/api/admin/settings -H 'Content-Type: application/json' -H 'Cookie: session=REGULAR_USER_SESSION' -d '{"maintenance_mode":true}'
# {"deleted":true,"user_id":1}
# {"maintenance_mode":true,"updated_by":"regular_user"}
```

A 200 response with data from an admin endpoint using a regular user session confirms broken access control. Also test with no session cookie at all. Some endpoints check for authentication but not authorization, so any logged-in user gains access. If GET returns 403 but POST is not tested, try switching the HTTP method. REST APIs that enforce role checks on read operations sometimes skip them on write operations, or vice versa.

## Race Conditions

Race conditions in business logic occur when two requests interact with the same resource before either completes. The classic case is redeeming a single-use discount code twice by sending both requests simultaneously. The server checks whether the code is used, both reads return "unused", and both apply the discount before either marks it as consumed. The same pattern applies to balance transfers, vote submissions, coupon redemptions, and any operation with a check-then-act sequence. For a deeper walkthrough of race condition techniques and tooling, see [race condition exploitation](https://hackindex.io/services/web/exploitation/race-condition-exploitation).

```bash
seq 1 20 | xargs -P 20 -I {} curl -sk -X POST http://$TARGET_IP:$PORT/api/coupon/redeem -H 'Content-Type: application/json' -H 'Cookie: session=YOUR_SESSION' -d '{"code":"SINGLEDISCOUNT"}'
# {"status":"applied","discount":"50%"}
# {"status":"applied","discount":"50%"}
# {"status":"already_used"}
# {"status":"already_used"}
```

> [!NOTE]
> If more than one request returns `applied`, the application is vulnerable to race condition abuse. The number of successful applications depends on the server's concurrency handling and database locking strategy. Increase the parallelism (`-P` value) and repeat multiple times, since race conditions are timing-dependent and may not trigger on every attempt.

Burp Suite's Repeater has a "Send group in parallel" feature that sends multiple tabs simultaneously using a single TCP connection. This produces tighter timing than shell-based parallel requests and is the most reliable method for triggering race conditions in web applications.

## Identifying Application-Specific Logic Flaws

Business logic flaws require manual analysis of the application's workflow. There is no generic scanner for these. Start by mapping all functionality: registration, authentication, checkout, profile management, file uploads, messaging, permissions, and any multi-step process. For each function, identify the assumptions the application makes and test whether the server enforces them.

Key areas to probe:

- Can you skip steps in any multi-step process?
- Does the server recalculate totals or trust the client-submitted values?
- Are role and permission checks applied at the API level or only in the UI?
- Can actions be performed out of the expected order?
- Do rate limits or single-use constraints hold under concurrent requests?
- Are state transitions enforced? Can an order go from "cancelled" back to "processing"?

Document each assumption you test, the request you sent, and the response. Logic flaws are harder to reproduce than technical vulnerabilities, so clear documentation with exact request/response pairs is critical for the report. Include the business impact: unauthorized purchases, privilege escalation, data access, or financial loss.

## References

- [PortSwigger: Business Logic Vulnerabilities](https://portswigger.net/web-security/logic-flaws) - Labs and methodology for identifying logic flaws in web applications.
- [OWASP: Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/) - Testing guide covering all categories of business logic vulnerabilities.
- [PortSwigger: Race Conditions](https://portswigger.net/web-security/race-conditions) - Detailed coverage of race condition exploitation in web applications.
- [OWASP: Transaction Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) - Guidance on securing multi-step transactions against logic bypass.