Checklist gratuita · sin registro
La checklist de seguridad del vibe coder.
Los creadores de IA generan apps que parecen terminadas, y las carencias de seguridad rara vez se ven desde la pantalla. Estas son 15 comprobaciones sobre los problemas que aparecen con más frecuencia en las apps generadas con IA, cada una con una prueba que puede ejecutar usted mismo. Muchas guardan relación con los riesgos del OWASP Top 10. Empiece por los puntos de gravedad alta .
- 01Alta
Claves de API secretas en el código del front-end
Comprobación: Abra las herramientas de desarrollo de su navegador (pestañas Sources y Network) y busque “key”, “token” y “secret”. Las claves públicas, como la clave pública (anon) de Supabase o la clave pública de Stripe, están pensadas para ser visibles. Las claves secretas, las claves de rol de servicio y las claves de API de terceros (por ejemplo, una clave de OpenAI) no. Si encuentra alguna, traslade esa llamada al servidor y renueve la clave.
- 02Alta
Inicio de sesión que solo se aplica en el navegador
Comprobación: Copie la URL de una página a la que se accede con sesión iniciada y ábrala en una ventana privada, o llame a la API que usa sin una sesión. Si los datos siguen llegando, la comprobación de acceso está en la interfaz y el servidor no la está aplicando.
- 03Alta
Sin seguridad a nivel de fila ni reglas de acceso por usuario
Comprobación: Con la sesión del usuario A, cambie un identificador en una petición (o en la URL) por uno que pertenezca al usuario B. Si llegan los datos de B, el acceso no se está aplicando donde residen los datos.
- 04Alta
Tablas de la base de datos accesibles desde el navegador sin reglas de acceso
Comprobación: Si el navegador consulta directamente su base de datos (habitual con Supabase), solo es seguro cuando la seguridad a nivel de fila (row-level security) está activada en cada tabla expuesta, con políticas que se correspondan con sus reglas. Compruebe cada tabla en el panel de su base de datos. Una tabla sin seguridad a nivel de fila puede ser leída o modificada por cualquiera que tenga la clave pública.
- 05Alta
Sin validación de entradas en el servidor
Comprobación: Envíe datos inesperados directamente a la API en lugar de hacerlo por el formulario: texto muy largo, etiquetas script, tipos de datos incorrectos, cantidades negativas. Si el servidor los acepta, añada validación en el servidor; las comprobaciones solo en el formulario pueden eludirse.
- 06Alta
Secretos guardados en el repositorio de código
Comprobación: Busque en el repositorio y en su historial claves, contraseñas y valores de .env. Todo lo que encuentre debe renovarse (borrarlo de la última versión no basta) y trasladarse a variables de entorno o al almacén de secretos de su proveedor de alojamiento.
- 07Media
Sin limitación de peticiones
Comprobación: En su propia app, llame muchas veces seguidas y con rapidez a un inicio de sesión, un registro o un endpoint con IA. Si nada le frena, está expuesto a intentos de adivinar contraseñas, registros de spam y facturas de uso inesperadas.
- 08Media
CORS demasiado permisivo
Comprobación: Compruebe de qué sitios web acepta su API peticiones desde el navegador. Un comodín (*) es aceptable para datos realmente públicos; para todo lo que esté tras un inicio de sesión, permita únicamente sus propios dominios.
- 09Media
Páginas o peticiones que no usan HTTPS
Comprobación: Confirme que todas las páginas se cargan por HTTPS y que la consola del navegador no muestra advertencias de “contenido mixto” en scripts, imágenes o llamadas a la API.
- 10Media
Mensajes de error que revelan el funcionamiento interno
Comprobación: Provoque un error, por ejemplo enviando un formulario defectuoso o visitando un registro inexistente. Si los usuarios ven trazas de la pila, consultas a la base de datos o rutas de archivos, registre el detalle de forma privada y muestre en su lugar un mensaje sencillo.
- 11Alta
Endpoints de administración o internos sin proteger
Comprobación: Haga una lista de todas las páginas de administración, rutas internas de la API y tareas programadas. Cada una debe exigir un usuario con sesión iniciada y el rol adecuado. Una URL difícil de adivinar no es una protección.
- 12Alta
Contraseñas gestionadas de forma insegura
Comprobación: Las contraseñas deben cifrarse con hash mediante un servicio o una biblioteca de autenticación probados, y nunca guardarse en texto plano ni escribirse en los registros. Si la herramienta de IA escribió su propio sistema de inicio de sesión, sustitúyalo por un proveedor de autenticación gestionado.
- 13Media
Dependencias sin revisar
Comprobación: Ejecute la auditoría de su gestor de paquetes (npm audit, por ejemplo) para detectar vulnerabilidades conocidas, actualice lo que señale y elimine los paquetes que la app ya no use.
- 14Media
Subida de archivos sin restricciones
Comprobación: Si los usuarios pueden subir archivos, compruebe que el tipo y el tamaño están limitados en el servidor, que los archivos subidos no pueden ejecutarse como código y que los archivos privados no son accesibles en una URL pública o fácil de adivinar.
- 15Alta
Sin copias de seguridad ni plan de recuperación
Comprobación: Confirme que la base de datos se copia automáticamente, compruebe hasta qué fecha puede restaurar y haga una restauración de prueba. Una copia que nadie ha restaurado es una suposición, no un plan.
FAQ
Preguntas frecuentes
¿Es seguro el vibe coding?
Para prototipos, sí. En cuanto una app guarda datos reales de clientes o cobra pagos, necesita las mismas comprobaciones de seguridad que cualquier otro software, y las apps creadas con IA suelen omitir algunas: claves secretas en el código del navegador, controles de acceso que solo existen en la interfaz, tablas de base de datos sin reglas de acceso y entradas que el servidor nunca valida. La app puede parecer terminada mientras existen estas carencias. Esta checklist le ayuda a encontrarlas antes de que los clientes dependan de la app.
¿Cuáles son los problemas de seguridad más comunes en las apps generadas con IA?
Los que más vemos son claves secretas expuestas en el código del front-end, inicios de sesión aplicados solo en el navegador, falta de seguridad a nivel de fila (de modo que un usuario puede leer los datos de otro) y ausencia de validación en el servidor. Varios corresponden a categorías del OWASP Top 10 (edición de 2025), la lista de riesgos de seguridad de aplicaciones web más utilizada, como Broken Access Control y Authentication Failures. Todos tienen solución.
¿Cómo protejo una app que creé con Lovable, Bolt o Replit?
Empiece por los puntos de gravedad alta: traslade las claves secretas al servidor, aplique el inicio de sesión y las reglas de acceso en el servidor o en la base de datos, active la seguridad a nivel de fila en cada tabla expuesta y valide las entradas en el servidor. Después avance por los puntos de gravedad media. Si prefiere que lo hagan ingenieros, podemos revisar la app y decirle lo que hay que corregir.
¿Ha encontrado puntos que no sabe cómo corregir?
Envíenos la app o el repositorio. La revisaremos, le diremos qué problemas son reales y cuáles están bien como están, y cuánto trabajo suponen las correcciones.