Los agujeros de seguridad que el vibe coding no deja de publicar

Todo lo que se envía al navegador puede leerlo la persona que lo usa. En Next.js, una variable con el prefijo NEXT_PUBLIC_ se inserta en el paquete del cliente. Eso es correcto para IDs de analítica y claves públicas de cliente. Es una filtración para contraseñas de bases de datos, claves secretas de proveedores de modelos y tokens de administración.

Prueba concreta: compila la app, abre su JavaScript en DevTools y busca los prefijos que usan tus proveedores. Después enumera cada coincidencia. Para cada una, debes poder explicar por qué es seguro que sea pública. Mueve cada credencial privilegiada detrás de un límite solo de servidor y rótala si ya se ha publicado.

Iniciar sesión responde una pregunta: ¿quién eres? La autorización responde otra: ¿puedes tocar este objeto concreto? Un endpoint puede acertar la primera y aun así exponer los datos de otro cliente.

Piensa en GET /api/invoices/inv_1042. El usuario A es dueño de esa factura y debe recibir 200. El usuario B puede ver el mismo ID en una captura compartida, una URL o un registro de red. Si el usuario B repite la petición y también recibe 200, la app tiene la autorización por objeto rota. La respuesta correcta es 403 o 404, aplicada en el servidor para ese objeto.

Wiz encontró en Base44 un flujo de registro y OTP que permitía a una persona externa entrar en apps privadas con acceso solo por SSO usando un ID visible en la URL. Lovable confirmó después que una regresión del backend expuso el historial de chat y el código fuente de proyectos públicos a otros usuarios autenticados. Ambos productos corrigieron los fallos reportados. La lección útil está en el límite: conocer un ID o haber iniciado sesión no demuestra que exista permiso.

No existe una frase honesta que diga que Supabase o Firebase es seguro o inseguro por defecto. Supabase activa la seguridad a nivel de fila para las tablas creadas en su panel, pero las tablas creadas con SQL necesitan activarla de forma explícita. El modo de producción de Firestore bloquea las lecturas y escrituras del cliente, mientras que el modo de prueba las permite. El resultado lo deciden tus políticas reales.

Moltbook es el ejemplo reciente más claro. Wiz encontró una clave pública de Supabase en el frontend y un backend sin las políticas de fila necesarias. La clave pública no era la vulnerabilidad por sí sola. La falta del límite en la base de datos la convirtió en acceso de lectura y escritura sin autenticar, exponiendo 1,5 millones de tokens de autenticación de API, 35.000 correos y mensajes privados. El equipo protegió la base de datos tras el aviso.

La prueba es simple: comprueba la capa de datos directamente como usuario anónimo, como propietario y como otro usuario autenticado. Un botón oculto no demuestra nada. La base de datos o el servidor debe rechazar la petición prohibida.

La autorización es lógica de negocio. Un modelo puede ver una tabla llamada invoices, pero no puede deducir si un contable puede leer todas las facturas de una empresa, solo las que creó o ninguna después de dejar el equipo. Esas reglas viven entre rutas, consultas, roles y eventos del ciclo de vida. Hay que definirlas y probarlas como un sistema.

Veracode probó más de 100 modelos con 80 tareas de programación y encontró un fallo conocido en el 45 % de las soluciones generadas. La prueba cubría inyección SQL, cross-site scripting, inyección en registros y criptografía débil. No probaba aplicaciones completas ni autorización por objeto, así que demuestra que el código generado necesita revisión, no que el 45 % de las apps creadas con IA sean inseguras.

Puedes detectar los fallos de acceso más obvios con dos cuentas de prueba y una revisión centrada en el producto.

• Intenta leer los datos de otra persona: Inicia sesion como usuario A, fijate en el ID de una peticion (una URL como /api/items/57, o una llamada de red), y repitela con la sesion del usuario B. Si B ve los datos de A, tienes el control de acceso roto.
• Cierra sesion y llama igualmente: Abre la pestaña de red, cierra sesion y repite tus llamadas a la API sin sesion. Todo lo que siga devolviendo datos reales esta sin proteger.
• Busca secretos en tu paquete: Busca en el JavaScript que publicas los prefijos de clave de tu proveedor y palabras como "secret" o "key". Una credencial activa en el navegador ya esta filtrada.
• Haz que la base de datos diga que no: Ejecuta lecturas, escrituras y borrados permitidos y prohibidos contra tus políticas reales. Comprueba el resultado esperado en vez de tratar una respuesta vacía como prueba.
• Pon nombre al guardia de cada ruta: Para cada endpoint, responde quien tiene permiso para llamarlo y donde se aplica eso en el servidor. Si la respuesta es "el frontend esconde el boton", no esta protegido.

El vibe coding sirve para llegar rápido a un producto que funciona. Funcionar no es lo mismo que estar protegido. Antes de usar datos reales, escribe la regla de acceso para cada objeto sensible, aplícala en el servidor o la base de datos y demuestra que el recorrido prohibido falla.