Find Business Logic Flaws with Burp Suite (2026)

Burp Suite’s core strength isn’t finding security flaws, but revealing the hidden, often illogical, assumptions baked into your application’s business logic.

Let’s say you’re testing an e-commerce site. You add an item to your cart, then proceed to checkout.

GET /cart HTTP/1.1
Host: example.com
Cookie: sessionid=abcdef123456

HTTP/1.1 200 OK
Content-Type: application/json
...
{
  "items": [
    {"product_id": "XYZ789", "quantity": 1, "price": 50.00}
  ],
  "total": 50.00
}

Then, during checkout, you might see a request like this:

POST /checkout HTTP/1.1
Host: example.com
Cookie: sessionid=abcdef123456
Content-Type: application/json

{
  "shipping_address": "123 Main St",
  "payment_method": "credit_card",
  "items": [
    {"product_id": "XYZ789", "quantity": 1}
  ]
}

The server processes this, and you get a confirmation. Now, the "business logic flaw" hunt begins.

What if you could modify the quantity of an item after it’s in the cart but before the final payment is confirmed? Or what if you could change the price of an item in the checkout request, even though it was displayed differently in the cart?

Burp Suite’s Intercept feature is your gateway. You configure your browser to proxy through Burp, and then you can watch every HTTP request and response flowing between your browser and the server.

The key is to think like a user with malicious intent, but not necessarily to hack the system. Instead, you’re trying to break its expectations.

Common Business Logic Flaws and How to Find Them with Burp:

1. Price Manipulation:

   • Diagnosis: Observe the HTTP requests during the checkout process. Look for parameters that represent the price of items. In the POST /checkout request above, if the price field was present and editable, that’s a direct target.
   • Check: Manually edit the price parameter in Burp’s Repeater tab to a significantly lower value (e.g., 0.01) and resend the request.
   • Fix: The application should validate the price against a known, server-side stored price for that product ID, or at least against a reasonable range. The server should never trust the price sent by the client during checkout.

2. Quantity Manipulation (Post-Cart):

   • Diagnosis: Similar to price manipulation, examine the checkout request for quantity parameters. If you can change the quantity here to a higher value than what was initially added to the cart, that’s a potential flaw.
   • Check: In Burp Repeater, increase the quantity parameter in the checkout request to an absurdly high number (e.g., 9999) and send.
   • Fix: The server must re-verify the total quantity of each item against the state of the user’s session or database cart before finalizing the order. It should not rely on the quantity sent in the final checkout payload if it differs from the confirmed cart.

3. Discount Code Abuse:

   • Diagnosis: Look for requests that apply discount codes. Often, these are separate requests (e.g., POST /apply_discount) or parameters within the checkout request.
   • Check: Try applying a valid discount code multiple times. Try applying a discount code after the order total has been calculated and sent. Try using expired or invalid codes.
   • Fix: Discount codes should be applied only once per order, and their validity and expiry must be checked server-side against a live, trusted list. The application should not allow applying discounts to already discounted items without explicit rules.

4. Rate Limiting Bypass (for specific actions):

   • Diagnosis: Identify actions that should be rate-limited, like password resets, one-time code generation, or even adding items to a cart if there are stock limits. Observe the requests for these actions.
   • Check: Use Burp’s Intruder to rapidly send the same request multiple times. If you can bypass the expected limit (e.g., request 100 password reset emails in a minute), you’ve found a flaw.
   • Fix: Implement robust server-side rate limiting for sensitive or resource-intensive operations, keyed by IP address, user ID, or session token, with appropriate delays and blocking mechanisms.

5. State Manipulation (e.g., Order Status):

   • Diagnosis: When an order is placed, it goes through stages (pending, processing, shipped, delivered). Look for requests that might update or query order status.
   • Check: If you can intercept a request that updates an order’s status (e.g., from "processing" to "shipped") without proper authorization or verification, you can manipulate it. This is less common in simpler apps but critical in complex workflows.
   • Fix: All state transitions for critical entities like orders must be strictly controlled by server-side logic, requiring proper authentication, authorization, and validation of the transition itself.

6. Parameter Tampering (e.g., User ID, Account ID):

   • Diagnosis: Many requests will contain identifiers for the user, account, or current session. These are often found in cookies or request bodies.
   • Check: In Burp Repeater, change the user_id or account_id parameter to that of another user. If the server then performs actions on that other user’s data, that’s a critical flaw.
   • Fix: The server must always use the authenticated user’s session context to authorize any action. It should never trust an id parameter sent by the client that could refer to another entity.

The most insightful business logic flaws arise when you realize the application assumes certain things about its users or the data they send. Your job is to prove those assumptions wrong.

Once you’ve successfully manipulated prices or quantities, the next logical step is to explore how these changes might affect downstream systems, such as inventory management or accounting, which often have their own implicit trust boundaries.