Seguridad en pagos con vibe coding: dos vulnerabilidades que la IA siempre pasa por alto

En Habr ha aparecido un artículo práctico sobre seguridad de pagos en productos creados con ayuda de IA. Su autor, un vibe coder sin experiencia profesional en desarrollo, analiza dos vulnerabilidades que el código generado por redes neuronales reproduce de forma garantizada y describe los cinco niveles de protección a los que llegó por experiencia propia.

Por qué el código de IA en pagos es más peligroso que un error evidente

La tesis central del artículo: la red neuronal no escribe mal código, escribe código que parece funcionar. La diferencia es fundamental. El escenario básico funciona: el usuario hace clic en «pagar», el dinero llega, el test sale en verde. La vulnerabilidad permanece invisible justo hasta que la encuentra un atacante, y no el desarrollador.

«El error más caro en este trabajo no es que la red neuronal escriba mal código, sino que escribe código que parece funcionar», escribe el autor en su artículo de

Habr.

Por eso el módulo de pagos es una zona de riesgo especial: un error oculto aquí no significa que la aplicación se caiga, sino pérdidas financieras directas, para el producto o para los usuarios.

Dos brechas que la red neuronal reproduce de forma sistemática

El autor señala dos fallos característicos del código de pagos generado por IA:

• Manipulación del precio: el servidor acepta el importe del cuerpo de la petición del cliente sin compararlo con el precio real en la base de datos. Un atacante cambia el valor en DevTools y paga el producto por una cantidad arbitraria, incluso por 1 rublo.
• Ausencia de verificación de webhooks: el servidor acepta notificaciones de pago sin comprobar la firma de la pasarela de pago. Esto permite enviar una confirmación falsa de la transacción y acceder al producto sin un pago real.
• Los asistentes de IA reproducen ambos patrones con regularidad: en los datos de entrenamiento, estas comprobaciones suelen aparecer como «detalles de implementación» y se omiten.

Según el autor, la red neuronal no cierra ninguna de estas vulnerabilidades de forma automática: hay que pedirlo de manera explícita o revisarlo a mano después de generar el código.

Cómo comprobar el producto antes del lanzamiento

El autor describe una técnica concreta: antes de entregar el producto, abrirlo en modo incógnito, sin tokens, cookies ni autenticación guardados, e intentar realizar un pago con los parámetros de la petición modificados. El objetivo es simular las acciones de un atacante mientras aún hay tiempo de corregir el código.

Para un vibe coder sin equipo ni code review, esta técnica sustituye a la vez la auditoría de seguridad y las pruebas: la única barrera real es mirar el producto desde el punto de vista del atacante.

Cinco niveles de protección

El artículo describe cinco niveles de protección del módulo de pagos que el autor desarrolló en la práctica. Según sus palabras, la IA omite los cinco en la primera generación: sin una petición explícita en el prompt o sin una revisión manual, no estarán en el código. Los detalles de cada nivel figuran en el texto completo; según el artículo, cubren la validación de datos entrantes en el servidor, la protección frente a peticiones repetidas y la auditoría de los eventos de pago.

Qué significa esto

El vibe coding ha reducido la barrera de entrada al desarrollo, pero no ha cambiado los requisitos de seguridad que el mundo real exige a los productos con pagos. La IA genera con soltura la lógica básica de los flujos, pero omite de forma sistemática la protección en el punto de unión entre cliente y servidor. Quienes construyen productos con redes neuronales necesitan una lista de comprobación explícita para los puntos críticos, o una costosa lección en producción.

Preguntas frecuentes

¿Qué vulnerabilidades pasa por alto la red neuronal en el código de pagos?

Según el autor del artículo en Habr, se omiten de forma sistemática dos patrones: la manipulación del importe del pago en el lado del cliente (el servidor acepta el precio de la petición sin compararlo con la base de datos) y la ausencia de verificación de la firma del webhook de la pasarela de pago. Ambos permiten completar una transacción sin un pago real.

¿Cómo puede un vibe coder comprobar la seguridad de los pagos antes

del lanzamiento?

El autor recomienda la técnica de la sesión limpia: abrir el producto en modo incógnito, sin autenticación, e intentar realizar un pago con parámetros modificados. Así se simulan las acciones de un atacante y se puede detectar la vulnerabilidad antes de pasar a producción, sin equipo ni code review.