Lógica de negocio, precios y cupones

La guía de pruebas de OWASP dedica una sección entera a la lógica de negocio, con pruebas como WSTG-BUSL-01 (validación de datos de la lógica de negocio), WSTG-BUSL-02 (capacidad de falsificar peticiones) y WSTG-BUSL-05 (límites de veces que se puede usar una función). En el Top 10 2025 de OWASP, su familia cae sobre todo bajo A06, «Insecure Design»: el fallo está en el diseño y no en una línea mal escrita.

Eso cambia el método. No se busca una cadena rara; se parte de las reglas del negocio («un cupón de bienvenida se usa una vez», «la cantidad mínima es uno», «el precio lo fija el catálogo») y se comprueba, una por una, si el servidor las hace cumplir o si confía en lo que le manda el navegador. Cada regla sin respaldo en el servidor es un hallazgo potencial.

Un límite de uso es una regla de negocio y, como todas, solo existe si el servidor la cuenta y la aplica. En la tabla de cupones de Despensa Andina cada fila tiene el máximo de usos que la regla declara y los usos que el servidor registró. Un contador que supera su máximo prueba que el límite no se estaba haciendo cumplir en el momento de canjear.

Abre el laboratorio y compara las dos columnas. Un cupón que llegó justo al máximo cumple su regla; el hallazgo es el que lo sobrepasa.

En la petición de pago de esta tienda viaja el precio unitario junto con el producto y la cantidad. Es una mala señal de diseño: el precio es una decisión del negocio, y si el servidor usa el valor recibido en lugar de consultar su catálogo, quien edite ese valor paga lo que quiera. La prueba 2 de la tabla es la evidencia de una compra de prueba en que el servidor aceptó un precio enviado menor que el de catálogo.

El impacto de un hallazgo así se expresa en dinero y se calcula con los datos: lo que debía cobrarse según el catálogo, menos lo que se cobró.

La prueba 3 envió una cantidad negativa y el servidor la procesó: calculó un total negativo para el pedido. Es un clásico de validación de datos de la lógica de negocio: la aplicación asume que nadie envía lo que el formulario no permite escribir. Un total negativo se puede traducir, según cómo siga el flujo, en un saldo a favor, un reembolso o una nota de crédito.

El hallazgo no es «el campo acepta un menos»: es que el servidor no valida el rango de la cantidad. La corrección vive allí, y su sitio no es el formulario del navegador, que cualquiera puede esquivar al hablar directamente con la API.

Estos hallazgos se redactan con la regla de negocio rota como protagonista. La estructura que le sirve al cliente es: la regla (qué debía ocurrir), la evidencia (la petición y el registro que muestran lo contrario, con cuentas y pedidos de prueba), el impacto en dinero o en operación, y la corrección. En el caso del precio, la corrección es que el servidor no reciba el precio: reconstruye el total desde el catálogo y la cantidad validada.

Evita dos errores. Uno, medir el impacto como si todos los pedidos futuros fueran a abusar del fallo: se estima con lo que la evidencia muestra y se dice qué se necesitaría para medir más. Dos, recomendar «monitorear» como única medida: vigilar ayuda, pero la regla sin hacerse cumplir sigue rota.