Платёжная безопасность при вибкодинге: две уязвимости, которые ИИ пропускает всегда

En Habr se publicó un artículo práctico sobre seguridad de pagos en productos construidos con IA: el autor — un vibe coder sin experiencia profesional en desarrollo — analizó dos vulnerabilidades que el código de redes neuronales reproduce de forma garantizada y describió 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 bug obvio

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

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

Habr.

Por eso precisamente el módulo de pago es una zona de riesgo especial: un error oculto aquí no significa la caída de la aplicación, sino pérdidas financieras directas — del producto o de los usuarios.

Dos agujeros que la red neuronal reproduce sistemáticamente

El autor identifica dos fallos característicos específicamente del código de pago generado por IA:

• Sustitución de precio — el servidor acepta el importe del cuerpo de la solicitud del cliente sin verificarlo contra el precio real en la base de datos. Un atacante cambia el valor en DevTools y paga el producto por cualquier cantidad arbitraria — incluso por 1 rublo.
• Ausencia de verificación de webhooks — el servidor acepta notificaciones de pago sin verificar la firma del sistema de pago. Esto permite enviar una confirmación de transacción ficticia y obtener acceso al producto sin un pago real.
• Ambos patrones son reproducidos regularmente por los asistentes de IA: en los datos de entrenamiento, dichas verificaciones suelen aparecer como «detalles de implementación» y se omiten.

Según el autor, ninguna de estas vulnerabilidades es cerrada automáticamente por la red neuronal — hay que solicitarlas explícitamente o verificarlas manualmente tras la generación del código.

Cómo verificar el producto antes del lanzamiento

El autor describe una técnica concreta: antes de entregar, abrir el producto en modo incógnito — sin tokens guardados, cookies ni autorización — e intentar procesar un pago con parámetros de solicitud modificados. El objetivo es imitar las acciones de un atacante mientras aún hay tiempo para corregir el código.

Para un vibe coder sin equipo ni code review, esta técnica sustituye tanto la auditoría de seguridad como las pruebas: la única barrera real es la propia mirada desde la perspectiva del atacante.

Cinco niveles de protección

El artículo describe cinco niveles de protección del módulo de pago que el autor desarrolló en la práctica. Según él, los cinco son omitidos por la IA en la primera generación — sin una solicitud explícita en el prompt o una verificación manual, no estarán en el código. Los detalles de cada nivel están en el texto completo: según el artículo, cubren la validación del lado del servidor de los datos entrantes, la protección contra solicitudes repetidas y la auditoría de eventos de pago.

Qué significa esto

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

Preguntas frecuentes

¿Qué vulnerabilidades omite la red neuronal en el código de pago?

Según el autor del artículo en Habr, se omiten sistemáticamente dos patrones: la sustitución del importe del pago en el lado del cliente (el servidor acepta el precio de la solicitud sin verificarlo contra la base de datos) y la ausencia de verificación de la firma del webhook del sistema de pago. Ambos permiten realizar una transacción sin un pago real.

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

del lanzamiento?

El autor recomienda la técnica de sesión limpia: abrir el producto en modo incógnito sin autorización e intentar procesar un pago con parámetros modificados. Esto simula las acciones de un atacante y permite identificar vulnerabilidades antes de salir a producción — sin equipo ni code review.