Business Logic Abuse
What it is
Abusing intended functionality in a way the application's rules never anticipated — not a technical injection, just performing steps in an order, combination or value range the logic didn't defend against: changing an email without confirming it, reusing a coupon, tampering with a price/quantity field client-side, joining a team without an invite.
Why it matters
These bugs are invisible to scanners and WAFs because every individual request looks perfectly valid — the flaw is in the sequence or the assumption, not the syntax. Programs value them highly because they map directly onto real financial or operational harm.
Where to look
- Checkout/cart flows, coupons, credits, gift cards, subscription plans
- Team/invite flows, multi-step wizards, any flow with a 'confirm later' step
How I test it
- Map the full happy path of a flow end to end, every step in order.
- At each step ask: what if I skip this, repeat this, do it out of order, or substitute a different value than the UI offers?
- Intercept and edit values the backend should be recalculating itself — price, quantity, discount, role — and see if it actually recalculates or just trusts the client.
- For price manipulation specifically: capture the cart/checkout request (
), change the price field directly ({"product_id": 123, "price": 99.99}
), and see if the final charge reflects it.{"product_id": 123, "price": 1.00} - Try replaying a step from a different account, or with a stale/expired session, to see if state assumptions hold.
Hunting checklist
- Mapped the complete happy path
- Tried skipping a step
- Tried repeating a one-time step
- Tried reordering steps
- Tampered with any client-visible price/quantity/role field
- Confirmed the backend doesn't recalculate the tampered value
- Tried the flow with a stale or cross-account session
Evidence to collect
- The full request sequence, in order
- The tampered request and its response
- Proof the final state (charge, balance, role) reflects the tampered value
- Clear real-world impact statement — money, access, or data affected
Recommended fix
- Recalculate all financial/authorization-relevant values server-side, never trust the client's copy
- Enforce step order and one-time-use constraints server-side
- Idempotency keys for anything that shouldn't be repeatable
Qué es
Abusar de una funcionalidad intencional de una forma que las reglas de la aplicación nunca contemplaron — no es una inyección técnica, es solo hacer los pasos en un orden, combinación o rango de valores que la lógica no defendía: cambiar un email sin confirmarlo, reutilizar un cupón, manipular un campo de precio/cantidad desde el cliente, unirte a un equipo sin invitación.
Por qué importa
Estos bugs son invisibles para escáneres y WAFs porque cada petición individual parece perfectamente válida — el fallo está en la secuencia o en la suposición, no en la sintaxis. Los programas los valoran mucho porque se traducen directamente en daño económico u operativo real.
Dónde buscar
- Flujos de carrito/checkout, cupones, créditos, gift cards, planes de suscripción
- Flujos de equipo/invitación, asistentes multi-paso, cualquier flujo con un paso de 'confirmar más tarde'
Cómo lo pruebo
- Mapea el camino feliz completo de un flujo, de principio a fin, paso a paso.
- En cada paso pregúntate: ¿qué pasa si me salto esto, lo repito, lo hago fuera de orden, o sustituyo un valor distinto al que ofrece la UI?
- Intercepta y edita valores que el backend debería recalcular por sí mismo — precio, cantidad, descuento, rol — y comprueba si de verdad los recalcula o solo confía en el cliente.
- Para manipulación de precio en concreto: captura la petición de carrito/checkout (
), cambia el campo precio directamente ({"product_id": 123, "price": 99.99}
), y comprueba si el cobro final lo refleja.{"product_id": 123, "price": 1.00} - Prueba repetir un paso desde otra cuenta, o con una sesión caducada/antigua, para ver si las suposiciones de estado se sostienen.
Checklist de hunting
- Mapeado el camino feliz completo
- Probado saltarse un paso
- Probado repetir un paso de un solo uso
- Probado reordenar pasos
- Manipulado algún campo de precio/cantidad/rol visible desde el cliente
- Confirmado que el backend no recalcula el valor manipulado
- Probado el flujo con una sesión antigua o de otra cuenta
Evidencias para el reporte
- La secuencia completa de peticiones, en orden
- La petición manipulada y su respuesta
- Prueba de que el estado final (cobro, saldo, rol) refleja el valor manipulado
- Explicación clara del impacto real — dinero, acceso o datos afectados
Mitigación
- Recalcular en servidor todo valor relevante para dinero/autorización, nunca confiar en la copia del cliente
- Forzar el orden de pasos y las restricciones de uso único en servidor
- Claves de idempotencia para cualquier cosa que no deba poder repetirse