Tu app generada con vibe coding funciona. Esto es lo que yo probaría antes del lanzamiento

He estado revisando aplicaciones web generadas con vibe coding desde una perspectiva de seguridad, UX y producto.

Lo interesante es que la funcionalidad principal suele funcionar.

Los problemas aparecen a su alrededor.

El registro funciona, pero la recuperación de cuenta no. El pago funciona con una tarjeta válida, pero los pagos fallidos dejan al usuario atascado. El panel de control oculta los datos de otro cliente en la interfaz, pero la API aún los devuelve.

Estos son algunos de los patrones que seguimos viendo.

1. La autorización existe en la interfaz, pero no en el servidor

Los botones de administrador se ocultan a los usuarios normales, pero los endpoints subyacentes no verifican el rol del usuario. En otros casos, cambiar un ID de cuenta o de registro es suficiente para acceder a los datos de otro cliente.

Ocultar algo en React no es control de acceso. Cada acción sensible debe autorizarse en el servidor.

2. Las reglas de Supabase o Firebase se tratan como detalles de configuración

La app funciona porque el acceso a la base de datos es permisivo. Luego llega a producción con políticas amplias de lectura o escritura aún habilitadas.

Prueba el acceso a la base de datos sin iniciar sesión. Pruébalo como un segundo usuario. Intenta leer y actualizar registros que pertenezcan a otra cuenta.

3. Se confía en el navegador con estado importante

Vemos roles, estado de suscripción, créditos y acceso a funciones controlados mediante localStorage o estado del lado del cliente.

Todo lo que el navegador pueda modificar debe considerarse no confiable. El acceso de pago, los roles, los saldos y los permisos deben provenir de un estado verificado en el servidor.

4. El éxito del pago se confunde con la verificación del pago

Algunas apps desbloquean un plan de pago porque el navegador llegó a una página de éxito. Esa redirección puede repetirse o manipularse.

El acceso debe concederse solo después de verificar el pago mediante la API del proveedor o un webhook firmado.

También prueba:

• Pagos fallidos y abandonados
• Entrega duplicada del webhook
• Flujos de actualización y degradación de plan
• Cancelación y renovación
• Reembolsos
• Confirmación de pago retrasada

5. Los secretos llegan al frontend

El código generado por IA a menudo se mueve rápidamente entre archivos del servidor y del cliente. A veces, las claves privadas de API terminan en los bundles del navegador, registros o variables de entorno públicas.

Busca en el JavaScript desplegado, no solo en el repositorio. Un secreto eliminado del código fuente más reciente puede seguir existiendo en un despliegue anterior.

6. El camino feliz está pulido, pero faltan las recuperaciones

Problemas comunes de UX incluyen:

• Formularios que pierden datos tras un error
• Estados de carga que parecen pantallas congeladas
• Estados vacíos sin una siguiente acción
• Sesiones expiradas que dejan al usuario varado
• Mensajes genéricos de "algo salió mal"
• Envíos duplicados al hacer clic dos veces en un botón
• Diseños móviles que ocultan controles importantes

Estos no son problemas cosméticos. Afectan la conversión, el volumen de soporte y la confianza del usuario en el producto.

7. Las subidas de archivos son más peligrosas de lo que parecen

Comprueba quién puede subir archivos, qué tipos de archivo se aceptan y si las URLs de almacenamiento son públicas. Verifica que un usuario no pueda sobrescribir o recuperar los archivos de otro usuario.

Los límites de tamaño de archivo, los nombres de archivo generados y la validación del lado del servidor también importan.

8. Los casos de abuso rara vez se incluyen en el prompt

Una función puede funcionar exactamente como se solicitó y aún así permitir:

• Uso ilimitado de correo electrónico o IA
• Reutilización de cupones
• Créditos autoasignados
• Pruebas gratuitas repetidas
• Envíos de spam
• Enumeración de cuentas
• Invitaciones no autorizadas

Una pregunta de revisión útil es: "Si alguien quisiera acceso gratuito, los datos de otro usuario o una forma de generarnos costos, ¿qué intentaría?"

Una prueba básica previa al lanzamiento

Antes de publicar, al menos haría lo siguiente:

1. Crear dos cuentas e intentar cruzar los límites entre cuentas.
2. Repetir las mismas pruebas sin iniciar sesión.
3. Inspeccionar el almacenamiento del navegador y las solicitudes de red.
4. Buscar en los activos desplegados claves privadas y secretos.
5. Probar pagos fallidos, retrasados y repetidos. También los casos en que el usuario cancela la suscripción desde el portal de pago.
6. Recargar o cerrar la página durante acciones importantes.
7. Probar cada formulario con datos faltantes, inválidos y duplicados.
8. Revisar la app en una pantalla móvil estrecha.
9. Confirmar que los roles y el acceso de pago se verifican en el servidor.
10. Probar límites, reintentos y fallos de terceros.

El vibe coding es muy bueno para lograr que la primera versión funcione. La suposición peligrosa es que "funcionar" y "estar lista para extraños en internet" significan lo mismo.

¿Qué problemas han encontrado ustedes después de que el flujo principal de su app ya funcionaba?

Aviso: Soy ingeniero de software con más de 15 años de experiencia. Mi equipo incluye ingenieros de seguridad y diseñadores de producto. Convertimos este proceso de revisión en AuditFlare, un servicio de auditoría de UX y seguridad dirigido por humanos para aplicaciones web generadas con vibe coding. Comparto esta lista porque estos problemas son útiles de probar, uses o no nuestro servicio.

Visto en r/vibecoding