After this lesson, you will be able to: Find business-logic vulnerabilities that automated scanners miss: price/quantity manipulation, workflow bypass, and trust-boundary violations, using Repeater and Intruder methodically.
Business-logic flaws are bugs in the application's intended workflow that let you do unintended things. Scanners cannot find them because they do not understand the business rules. This lesson teaches how to think about and find them.
These are flaws in how the application's intended workflow can be abused: not a missing filter, but a wrong assumption about how users will behave. A scanner sees valid requests and valid responses and finds nothing, because the requests are technically well-formed. Only a human who understands what the app is supposed to do can spot that a particular sequence or value breaks the intended rules.
Price manipulation: change a cart item's price in the request and see if the server trusts it. Quantity manipulation: negative quantities (refunding yourself), or values that cause integer overflow. Workflow bypass: skip a step in checkout or registration (jump straight to the confirmation endpoint). Trust-boundary violations: access functionality intended for a different role by calling its endpoint directly. The theme is the server trusting client-supplied state it should recompute or check.
First, understand the intended functionality completely (use the app as a normal user). Then ask: what happens if I do this out of order, with this unexpected value, or as this user type? Methodically explore every numeric and boolean parameter for manipulation in Repeater, and use Intruder to sweep a range (every quantity from -10 to 1000). The mindset, not a tool, finds these bugs.
Use PortSwigger's Business Logic labs.
1. Complete the PortSwigger Business Logic labs series (11 labs, apprentice to expert).
2. For each, first map the intended workflow, then identify the assumption the developer made.
3. Break that assumption in Repeater (a wrong value, a skipped step, an unexpected role).
4. For each finding, write the business impact in plain terms (e.g. 'a customer can buy any item for $0').
Pick the best reason.
Skipping the 'understand the intended workflow' step and flailing. Testing only the happy path. Forgetting negative numbers, zero, and huge values. Assuming the server re-checks client-supplied prices/totals (it often does not). Not framing the finding in business-impact terms, which is what gets it taken seriously. Expecting a tool to find these instead of thinking like an abuser of the workflow.
Sign in and purchase access to unlock this lesson.