Modelar el flujo esperado y sus invariantes

Las inyecciones y los errores de configuración tienen forma: una comilla de más, una cabecera que falta, una versión vieja. Un fallo de lógica de negocio usa la aplicación tal como fue construida, con peticiones que se ven normales, y aun así consigue algo que el negocio no quería: pagar menos, usar dos veces lo que era de una, saltarse un paso. MITRE agrupa estos errores en la categoría CWE-840 (errores de lógica de negocio), y el Top 10 de OWASP de 2025 los cubre dentro de A06:2025, diseño inseguro: el problema no es un descuido al programar sino una regla que nunca se convirtió en control.

Por eso un escáner rara vez los encuentra. Para reconocer que algo salió mal hay que saber cómo debía salir, y eso no está en el código: está en las reglas del negocio.

Modelar el flujo es dibujar los estados por los que pasa un objeto del negocio (un pedido, una reserva, un pago), quién mueve cada transición y qué debe ser verdad en todo momento. A esas verdades se les llama invariantes: condiciones que se pueden comprobar con los datos y que ninguna secuencia de pasos, por rara que sea, debe romper. «El total es subtotal menos descuento más envío» es una invariante; «el cliente paga en la pantalla de pago» no lo es, porque describe una pantalla y no un hecho que se pueda verificar.

Abre el laboratorio y lee en la carpeta mecato-invariantes el flujo, las reglas R1 a R8 y el extracto de pedidos de octubre. Revisa la primera regla contra cada fila: lo pagado es la suma de billetera y tarjeta.

Una invariante escrita con precisión se convierte en una consulta: se recorren los datos y se cuentan las filas que la rompen. Eso es lo que permite pasar de «contabilidad no cuadra» a «estos pedidos violan esta regla». Aplica las tres primeras reglas a cada pedido del extracto: lo pagado igual al total, el total bien calculado y el descuento que no supera el subtotal. Un pedido puede romper más de una; cuéntalo una sola vez.

Encontrar la violación en los datos de octubre es investigar. Evitar la de noviembre exige que la invariante viva en el sistema: en el servidor, en el punto exacto donde ocurre la transición que la puede romper, y si se puede también como restricción de la base de datos. Comprobarla en la interfaz no sirve, porque la petición la arma el cliente; comprobarla en un informe mensual llega tarde.

El borrador del equipo traduce casi todas las reglas a condiciones comprobables, pero mezcla una que describe la interfaz. Es un error común y tiene consecuencias: quien lea la lista creerá que la regla ya está cubierta. Además, una de las reglas de producto no tiene ninguna invariante en el borrador.