Business Logic Flaws

Severity: High

Every request is valid. The sequence is the bug.

What it is

A business-logic flaw is the application doing exactly what it was built to do, in a situation its designers never pictured. Nothing is malformed, so no scanner and no input filter will ever catch it — the input is legal, the outcome is not.

The usual root cause is an assumption that lives in the developer's head rather than in the code: quantities are positive, a discount applies once, the client will send the price the server showed it, steps happen in order, a total cannot go below zero.

These bugs pay well on real programmes because their impact is easy to state in the business's own currency — money, stock, credits, records — and because they tend to survive for years in otherwise well-hardened code.

How to approach it

Use the feature honestly first and write down the rules it seems to enforce: limits, prices, eligibility, order of steps.
For each rule, ask where it is actually enforced. If the client sends a value the server should have computed, that value is a lever.
Push numeric inputs to their edges: zero, negative, very large, fractional, repeated.
Repeat steps that should happen once, skip steps that should be mandatory, and change the order of a multi-step flow.
Measure the outcome in the app's own terms. 'I paid less than I should have' is a finding; 'the number looked odd' is not.

How you'll recognise it

The tells that should make you slow down and test this class properly.

Prices, totals, quantities or discounts that travel in your requests.
Coupons, credits, referrals or loyalty points — anything that changes a balance.
Multi-step flows (cart → checkout → confirm) where each step is a separate request.
Rules that are explained in the UI but have no visible server-side error when broken.

Your task

Complete a purchase the store's own rules say you cannot afford, then acquire the item it says is not for sale.

▶ Access the lab

Opens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.

Proving it to a triager

On a real programme the report is what gets paid. What the evidence needs to show, and what usually gets it closed.

Show the honest baseline first, then the request sequence that breaks the rule, then the resulting state.
Quantify in money or records — this is the line triage scores on.
Reverse or cancel what you can after proving it, and say so.
Common N/A: an odd number on screen that the server later rejects or reconciles.

🎓 Want the full course? — from Uncle Rat, half price with code DISCOUNT

013 CAPIJ — Certified API Hacking Junior ↗ API hacking as a certification track, junior level. 052 Postman 101 ↗ Drive an API properly before you start bending its logic.

How to prevent it

Compute every security-relevant value server-side — prices, totals, eligibility — and ignore any client-submitted equivalent.
Validate ranges and types on the server: quantities must be positive integers within sensible bounds.
Make one-time actions idempotent and record that they happened, server-side, before applying them.
Write tests for the abuse cases, not only the happy path: negative, repeated, out of order.

More Business Logic labs

Race Conditions — Fire the same action many times at once and slip through the gap before the check catches up.
Mass Assignment — Send fields the form never showed you, and the server saves them anyway.

← All labs