Condición de carrera (Race condition)
En seguridad de aplicaciones, una condición de carrera es un fallo en el que el resultado depende del orden en que se procesan peticiones concurrentes, porque una comprobación y la acción que autoriza no son atómicas. Enviar la misma petición muchas veces en paralelo hace que la aplicación actúe sobre un estado que ya ha invalidado.
La forma clásica es pasarse de un límite: un cupón marcado como de un solo uso, una retirada de fondos comprobada contra un saldo, una invitación que da una plaza. El código lee el estado, decide que la acción está permitida y escribe el resultado, y entre la lectura y la escritura otra petición ya ha pasado la misma comprobación. La ventana suele ser de unos pocos milisegundos, y por eso sobrevive a las pruebas funcionales y aparece en una auditoría como fallo de lógica de negocio.
Explotarlo es un problema de sincronía, no de volumen, así que no es lo mismo que derrotar el rate limiting. Lo que funciona es enviar las peticiones para que lleguen juntas y no deprisa: agruparlas para que los últimos bytes de cada una salgan a la vez elimina casi todo el jitter de red que si no las separa. Si un objetivo es alcanzable y el límite se aplica en el código de la aplicación y no en la base de datos, merece la pena probarlo.
En un informe el hallazgo se escribe contra la transacción y no contra el endpoint, y la evidencia es el estado resultante: dos usos aceptados de un token de un solo uso, un saldo por debajo de cero, dos cuentas ocupando una plaza. El arreglo es una restricción o un bloqueo a nivel de base de datos, y esto forma parte de las pruebas de aplicación web donde la concurrencia entra en la revisión de la lógica.