Vibe coding y seguridad: los riesgos reales y cómo evitarlos

El vibe coding (crear software describiéndole a una IA lo que quieres, sin escribir el código tú) es rapidísimo, pero tiene un punto ciego claro en seguridad: la IA se enfoca en que la app funcione, no en que solo las personas correctas puedan ver y cambiar los datos. El resultado típico es una app que se ve terminada, pero con la base de datos abierta, llaves secretas visibles en el navegador o pantallas de administrador sin protección real.

Si no te queda claro el término, aquí explicamos qué es el vibe coding. Este post va directo a los riesgos y cómo revisarlos.

Los 6 riesgos de seguridad más comunes del vibe coding

1. Base de datos sin reglas de acceso

Herramientas como Lovable o Bolt suelen conectar tu app a Supabase, una base de datos que el navegador consulta directamente. Para que eso sea seguro, cada tabla necesita RLS (Row Level Security: reglas que dicen qué filas puede ver o cambiar cada usuario). Sin RLS, cualquiera con la llave pública puede leer o escribir toda la tabla.

No es hipotético: la vulnerabilidad CVE-2025-48757 (mayo 2025) documentó que 170 de 1,645 apps de la vitrina de Lovable dejaban leer o escribir tablas de Supabase con la llave pública anon. Te explicamos qué es RLS en Supabase.

2. Llaves secretas en el frontend

El “frontend” es el código que se descarga al navegador de tu visitante; todo lo que esté ahí, cualquiera lo puede ver. Si la IA pegó ahí tu llave service_role de Supabase, tu llave de Stripe o de OpenAI, alguien puede usarla a tu nombre. Revisa qué hacer con una API key expuesta.

3. Seguridad “de adorno”

Es común que la IA oculte un botón de “Admin” si no eres administrador, pero que la ruta o la consulta a la base de datos sigan abiertas. Ocultar algo en pantalla no es protegerlo. La validación tiene que estar en el servidor o en la base de datos.

4. Dependencias y paquetes inventados o viejos

La IA instala librerías para resolver cosas. A veces son versiones con vulnerabilidades conocidas; a veces sugiere paquetes con nombres que no existen o que suenan parecido a uno real, y alguien malicioso pudo publicarlos con ese nombre.

5. Entradas sin validar

Formularios que aceptan cualquier cosa: textos gigantes, código, archivos de cualquier tipo. Eso abre la puerta a inyecciones y a que suban archivos dañinos a tu almacenamiento.

6. Sin respaldos ni registros

Si algo sale mal, no sabes qué pasó ni puedes volver atrás. Respaldar con regularidad es parte de la seguridad.

Cómo revisar la seguridad de tu app hecha con vibe coding

No necesitas ser programador para hacer estas pruebas básicas en tu propia app:

1. Crea dos cuentas de prueba (A y B). Con la cuenta A, intenta abrir la URL de un registro de B (por ejemplo, cambia el número o el id en la dirección). Si lo ves, tienes un problema de permisos.
2. Revisa el panel de Supabase. En Table Editor cada tabla debe mostrar RLS activado. En el Security Advisor de Supabase aparecen avisos como “RLS disabled in public”; aquí explicamos cómo resolverlo.
3. Busca llaves en el navegador. Abre tu app, F12 → pestaña Sources o Network, y busca service_role, sk_live, secret. La llave anon de Supabase sí puede estar en el frontend; la service_role nunca.
4. Revisa las variables de entorno. Los secretos deben vivir en variables de entorno del servidor, no en el código.
5. Prueba sin sesión. Cierra sesión y entra directo a rutas como /admin o /dashboard. Deberían mandarte al login y no cargar datos.

Si tu código está en tu computadora, una búsqueda rápida ayuda:

grep -rniE "service_role|sk_live|apikey|secret" src/ --include=*.{js,ts,tsx,jsx}

Y en Supabase, esta consulta te dice qué tablas del esquema público no tienen RLS:

select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Cómo pedirle a la IA que programe más seguro

Ayuda incluir esto en tus instrucciones a Lovable, Bolt, Cursor o Claude:

• “Activa RLS en todas las tablas y crea políticas para que cada usuario solo vea sus propios registros.”
• “Nunca pongas llaves secretas en el frontend; usa funciones del servidor (edge functions) para llamar APIs privadas.”
• “Valida en el servidor todo lo que llegue de formularios.”

Después, verifica con las pruebas de arriba. La IA a veces responde “listo, ya está seguro” sin haberlo hecho bien.

Errores comunes

• Pensar que “como nadie conoce mi app, nadie la va a atacar”. Hay programas que buscan apps de Supabase abiertas de forma automática.
• Desactivar RLS “temporalmente” para que deje de salir un error y olvidar volver a activarlo. Si te sale “new row violates row-level security policy”, la solución es corregir la política, no apagarla.
• Publicar con datos reales de clientes antes de hacer ninguna prueba.

Para cerrar

El vibe coding es una gran forma de construir rápido, pero antes de abrir tu app al público alguien tiene que revisar permisos, llaves y respaldos. Tenemos una checklist de seguridad para apps hechas con IA para hacerlo tú mismo. Si manejas datos personales o pagos, o no te sientes seguro con las pruebas, en Black Engine revisamos tu app por WhatsApp y te decimos qué corregir primero.