Cómo proteger una app hecha con vibe coding antes de compartirla
Respuesta rápida
Antes de que tus compañeros usen una app que creaste con IA, revisa cuatro cosas primero: nadie pasa sin el inicio de sesión de la empresa, solo entran las cuentas de tu empresa, no hay claves en el código que corre en el navegador y la base de datos no se puede leer sin pasar por la app. Después revisa quién puede hacer qué dentro de ella, y quién es el responsable cuando te vayas.
La mayoría de las filtraciones de apps hechas con IA no son ataques ingeniosos. Son puertas abiertas: un enlace público, una base de datos con sus reglas apagadas, una clave en la página. Esta checklist es para la persona que creó la app y para la persona de TI que la revisa. Cada punto dice qué sale mal, cómo revisarlo con palabras simples, y qué resuelve TeamOnly y qué sigue siendo tu responsabilidad.
Última actualización Escrito por TeamOnly. Alojamos apps internas creadas con IA, y cada punto dice con honestidad dónde ayudamos y dónde no.
01Por qué importa
Qué sale mal con las apps hechas con IA
Las herramientas de IA son buenas para hacer que una app funcione. Tienen menos cuidado con para quién más funciona. Tres hallazgos de los últimos dos años muestran el patrón.
380,000
recursos accesibles públicamente encontrados en Lovable, Base44, Netlify y Replit por la empresa de seguridad Red Access en mayo de 2026. Unos 5,000 tenían datos sensibles de empresas, y muchos estaban indexados por Google.
170 de 1,645
apps de Lovable revisadas en marzo de 2025 dejaban a cualquiera leer o cambiar datos en su base de datos de Supabase sin iniciar sesión, porque las reglas de acceso a la base de datos faltaban o estaban mal (CVE-2025-48757).
205,474
nombres de paquetes inventados que sugirieron 16 modelos de IA en 576,000 muestras de código, en un estudio de 2025. Los atacantes pueden publicar paquetes con esos nombres y esperar a que alguien los instale.
Ninguno de estos casos necesitó un atacante ingenioso. Las puertas estaban abiertas. Eso es una buena noticia: las puertas abiertas son fáciles de revisar, y no necesitas leer código para hacerlo.
Hazlas en orden. Las primeras dejan fuera a los extraños, las siguientes atrapan errores dentro de la empresa.
Nada carga antes del inicio de sesión de la empresa
Qué sale mal
Las herramientas de IA suelen crear la pantalla de inicio de sesión como una página más de la app. El resto de la app, y su API, siguen respondiendo a cualquiera que se salte esa página o llame a la API directamente. Red Access encontró apps de empresas que daban acceso de admin a cualquiera que llegara a la dirección.
Revísalo tú
Abre la app en una ventana privada del navegador. Deberías ver una pantalla de inicio de sesión y nada más. Luego pregúntale a tu herramienta de IA: “Haz una lista de todas las rutas de la API y dime cuáles funcionan sin iniciar sesión.” La respuesta debería ser ninguna.
En TeamOnly
Resuelto. Cada solicitud a cada app se revisa antes de que corra cualquier parte de tu código, incluidas las llamadas a la API, que reciben un 401 sin sesión. No hay ninguna opción para hacer pública una app.
Solo entran las cuentas de tu empresa
Qué sale mal
“Iniciar sesión con Google” deja entrar por defecto a cualquier cuenta de Google, incluido un Gmail personal. El parámetro hd de Google solo reduce el selector de cuentas, y Google advierte que no hay que confiar en él porque la solicitud se puede modificar. El dominio se tiene que revisar en el servidor.
Revísalo tú
Intenta iniciar sesión con una cuenta personal de Gmail u Outlook. Deberían rechazarte. Pregúntale a tu herramienta de IA dónde revisa el servidor el dominio del correo, y si revisa el token firmado de Google o un valor que mandó el navegador.
En TeamOnly
Resuelto. Los compañeros inician sesión con su cuenta de trabajo de Google, de Microsoft o con un código enviado a su correo de trabajo. El dominio del token de inicio de sesión verificado se compara con los dominios de tu empresa, y las cuentas personales se rechazan.
Solo las personas correctas dentro de la empresa
Qué sale mal
Una app con sueldos, evaluaciones o datos de clientes se comparte con toda la empresa porque esa era la opción por defecto. O la IA crea su propia lista de permitidos en el código que nadie actualiza.
Revísalo tú
Pregúntate: ¿todos en la empresa deberían ver estos datos? Si no, anota los nombres de quienes sí, y revisa que a alguien fuera de esa lista se le rechace.
En TeamOnly
Resuelto, tú eliges. El acceso es toda la empresa o una lista de nombres, configurado en el panel o con npx teamonly access only priya@acme.com. Se revisa en cada solicitud, así que quitar a alguien tiene efecto en menos de un minuto.
Ni en un enlace público ni en los resultados de búsqueda
Qué sale mal
Algunos creadores de apps publican en una dirección pública a menos que elijas privado. Las apps públicas se encuentran: Red Access informó que muchas de las apps de empresas expuestas estaban indexadas por Google y otros buscadores.
Revísalo tú
Busca en Google site: seguido de la dirección de tu app. Revisa la opción de visibilidad del proyecto en la plataforma donde lo creaste. Si dice público, cámbialo antes que cualquier otra cosa.
En TeamOnly
Resuelto. Las apps viven en yourapp.yourcompany.teamonly.app detrás de la pantalla de inicio de sesión. Cada respuesta, incluida la pantalla de inicio de sesión, les dice a los buscadores que no la indexen, y la pantalla de inicio de sesión solo muestra el nombre de la app y las formas de entrar.
Sin claves en el código que corre en el navegador
Qué sale mal
Las herramientas de IA ponen claves de API en el código React o en variables que empiezan con VITE_ o NEXT_PUBLIC_. Todo lo que se envía al navegador lo puede leer cualquiera que abra la app. Supabase dice que su clave secreta nunca debe estar en un navegador, porque se salta todas las reglas de la base de datos.
Revísalo tú
Pregúntale a tu herramienta de IA: “¿Hay alguna clave, token o contraseña en el código de la interfaz, en una variable VITE_ o en un archivo .env subido al repositorio?” En el navegador, abre las herramientas para desarrolladores y busca key, secret y sk_ en los archivos cargados. Si una clave quedó expuesta alguna vez, cámbiala en el servicio que la emitió.
En TeamOnly
En parte resuelto. Las claves se guardan con npx teamonly secrets set NAME, fuera del código, y solo el código de servidor de tu app puede leerlas. Las instrucciones que agrega TeamOnly le dicen a tu herramienta de IA que nunca use claves VITE_. Nada te impide pegar tú una clave en el código, así que igual revísalo.
La base de datos no se puede leer saltándose la app
Qué sale mal
Con Supabase y servicios parecidos, el navegador habla directamente con la base de datos y las reglas de acceso (row-level security) deciden qué puede ver. Cuando esas reglas están apagadas o mal, cualquiera con la clave pública puede leer o cambiar tablas enteras. Ese fue el hallazgo de Lovable.
Revísalo tú
En Supabase, abre Advisors y luego Security Advisor. Cualquier error “RLS disabled in public” significa una tabla que cualquiera puede leer. Que exista una regla no basta: inicia sesión como un compañero común e intenta abrir el registro de otra persona.
En TeamOnly
Resuelto para los de fuera. La base de datos de cada app no tiene dirección propia en internet. Solo se llega a ella a través del código de servidor de tu app, después de iniciar sesión. Qué filas puede ver cada persona con sesión iniciada sigue siendo algo que el código de tu app tiene que hacer bien (mira la revisión 8).
Los datos de cada app, separados
Qué sale mal
Varias apps comparten una base de datos o un bucket de almacenamiento porque era más rápido. Entonces una clave o un error en una app abre todas.
Revísalo tú
Pregúntate: ¿alguna otra app usa la misma base de datos, almacenamiento o claves que esta? Si es así, la app más débil decide qué tan seguras son todas.
En TeamOnly
Resuelto. Cada app recibe su propia base de datos, almacenamiento de archivos y secretos en la primera publicación, y su cookie de sesión está atada a su propia dirección. Las apps no pueden llegar a los datos de otras.
Quién puede hacer qué, revisado en el servidor
Qué sale mal
La IA oculta el botón Aprobar para la mayoría pero deja la ruta de aprobar abierta a cualquiera con sesión iniciada. O el servidor confía en un rol o un correo que manda el navegador. El control de acceso roto es el número uno del OWASP Top 10. La entrada sin revisar es un pariente: un monto negativo, una consulta SQL armada con un cuadro de texto.
Revísalo tú
Inicia sesión como un compañero común e intenta lo que solo deberían hacer los gerentes. Pregúntale a tu herramienta de IA: “Para cada ruta de la API, ¿quién puede llamarla y en qué parte del servidor se revisa? ¿Todas las consultas a la base de datos usan marcadores de posición?”
En TeamOnly
En parte resuelto. Tu app recibe la persona verificada (ctx.user) y los roles que repartes en el panel (ctx.user.roles), y se quitan los encabezados de identidad falsos. Las instrucciones le dicen a tu herramienta de IA que use marcadores de posición en las consultas y revise la entrada en el servidor. Revisar el rol en cada ruta es código de tu app. TeamOnly no lo revisa.
Cada paquete es real y necesario
Qué sale mal
Las herramientas de IA a veces sugieren paquetes que no existen. Los atacantes publican paquetes con esos nombres, así que instalar uno corre el código de un desconocido dentro de tu app.
Revísalo tú
Abre package.json. Busca en npmjs.com cualquier nombre que no reconozcas: un paquete real tiene historial, un repositorio de código enlazado y descargas constantes. Ejecuta npm audit antes de publicar, y quita los paquetes que la app ya no usa.
En TeamOnly
No resuelto. TeamOnly no escanea paquetes. Una app solo puede llegar a sus propios datos y claves, lo que limita lo que puede tocar un paquete malo, pero dentro de esa app igual podría leerlo todo.
Un registro de quién cambió qué
Qué sale mal
Algo se aprueba, se borra o se cambia y nadie puede decir quién lo hizo. Las apps hechas con IA rara vez guardan un historial a menos que lo pidas.
Revísalo tú
Pídele a tu herramienta de IA que registre quién creó y quién cambió por última vez cada registro, y cuándo, y que guarde una tabla de historial para aprobaciones y borrados. Pruébalo: cambia un registro y busca tu nombre en él.
En TeamOnly
En parte resuelto. El panel muestra cada publicación de cada app, con quién publicó y cuándo, y registros en vivo. Los registros son en vivo, no se guardan. Los registros de auditoría de inicios de sesión y cambios de acceso están en el plan Business, configurado contigo. El historial dentro de la app (quién aprobó un gasto) es trabajo de tu app.
Un responsable, una copia y un plan para cuando alguien se va
Qué sale mal
El creador se va y la app sigue corriendo en su cuenta personal, o se detiene cuando cancelan su tarjeta. O un cambio malo borra una tabla y no hay copia.
Revísalo tú
Anota quién es el responsable de la app y quién la toma después. Guarda el código en un repositorio Git de la empresa. Pídele a tu herramienta de IA que agregue una exportación CSV de las tablas principales, y pruébala.
En TeamOnly
En parte resuelto. Las apps pertenecen a tu empresa, y los admins pueden pasar una app a un nuevo responsable. Desactivar la cuenta de trabajo de alguien detiene los inicios de sesión nuevos. Las personas que ya iniciaron sesión siguen dentro hasta que termina su sesión, y los admins eligen cuánto dura, de 8 horas a 30 días. Hoy no hay botón de copia de seguridad ni de exportación en el panel, así que incluye la exportación en la app.
03Imprímelo
La revisión de un minuto
Once preguntas de sí o no. Cualquier “no” es lo siguiente que hay que arreglar.
Antes de compartir esta app
Una ventana privada del navegador muestra un inicio de sesión de la empresa y nada más.
Una cuenta personal de Gmail u Outlook es rechazada.
Solo las personas que necesitan estos datos pueden abrirla.
Una búsqueda site: de la dirección de la app no encuentra nada.
No hay ninguna clave, token ni contraseña en el código del navegador ni en el repositorio.
No se puede llegar a la base de datos sin pasar por la app.
Los datos y claves de esta app no se comparten con ninguna otra app.
Un compañero común no puede hacer lo que solo deberían hacer los gerentes.
Cada paquete de package.json es real y se sigue usando.
Los registros muestran quién los creó y quién los cambió.
Otra persona sabe que es responsable de esta app si me voy, y los datos se pueden exportar.
Quince minutos con el creador, con la pantalla compartida. Estás revisando la configuración, no leyendo cada línea de código.
Dónde vive y quién puede llegar a ella
Pide la dirección. Ábrela desde un dispositivo sin sesión iniciada, y desde una cuenta personal. Pregunta qué plataforma la aloja y qué cuenta la paga. Una cuenta personal es lo primero que hay que cambiar.
Qué datos guarda
Pregunta qué entra y de dónde viene. Datos personales de clientes, datos de pago, datos de salud o contraseñas de otros sistemas suben la exigencia, y pueden significar que la app debería limitarse a una lista de nombres.
Dónde están las claves
Haz una lista de cada servicio externo al que llama la app. Cada clave debería estar en la configuración de secretos del hosting, limitada a lo que la app necesita, y no compartida con otras apps. Rota cualquier clave que haya estado alguna vez en el código o en un chat.
Quién puede hacer qué
Pídele al creador que inicie sesión como usuario común, o pídeselo a un compañero, y prueben las acciones de admin. Pídele al creador que su herramienta de IA haga una lista de cada ruta de la API y dónde revisa el rol. Lo que falte aquí se arregla en el código de la app.
Paquetes y código
Miren juntos package.json y ejecuten npm audit. Pide que el código viva en un repositorio Git de la empresa, no solo en la laptop del creador.
El responsable, y el día que se vaya
Anota la app, su responsable, un responsable de respaldo, sus datos y sus usuarios en tu lista de apps. Acuerden qué pasa cuando el responsable se vaya. La guía de apps de shadow AI tiene una política de una página que puedes copiar.
¿Es seguro compartir apps hechas con vibe coding con los compañeros?
Puede serlo. Los problemas comunes están en dónde vive la app y cómo se configuró: un enlace público, sin un inicio de sesión de verdad, claves en el navegador, reglas de la base de datos apagadas. Cada uno se revisa en unos minutos. Haz la checklist de esta página antes de enviar el enlace.
¿Cuál es el mayor riesgo de seguridad en una app hecha con vibe coding?
Datos a los que cualquiera llega sin iniciar sesión. Suele pasar de dos maneras: la app está en un enlace público sin inicio de sesión delante, o la base de datos responde solicitudes directamente y sus reglas de acceso están apagadas (row-level security en Supabase). Las dos son de configuración, no de que la IA escriba mal código.
¿Es seguro poner mi clave anon de Supabase en el navegador?
La clave anon o publishable está hecha para estar en el navegador, pero solo porque row-level security limita a qué puede llegar. Si row-level security está apagado en una tabla, cualquiera con esa clave puede leerla y cambiarla. La clave secreta o service_role nunca debe estar en el navegador: se salta todas las reglas.
¿“Iniciar sesión con Google” limita una app a mi empresa?
No por sí solo. Por defecto cualquier cuenta de Google puede entrar, incluido un Gmail personal. El parámetro hd de Google solo reduce el selector de cuentas, y Google dice que no hay que confiar en él. El servidor de la app tiene que revisar el dominio en el token de inicio de sesión verificado en cada solicitud.
¿Cómo reviso si Google indexó mi app?
Busca en Google site: seguido de la dirección de tu app, por ejemplo site:myapp.lovable.app. Si aparecen páginas, la app es pública y está indexada. Haz la app privada o muévela detrás de un inicio de sesión de la empresa, y luego pídele a Google que quite las páginas con la herramienta Retiradas de Search Console si el dominio es tuyo.
¿Debería pedirle a mi herramienta de IA que escriba código seguro?
Sí, y es mejor darle instrucciones permanentes que pedirlo una vez. Un archivo de reglas en el proyecto (CLAUDE.md, AGENTS.md o una regla de Cursor) le dice a la herramienta dónde van las claves, cómo escribir consultas a la base de datos y dónde revisar los roles. npx teamonly init las agrega en las apps de TeamOnly. Después igual haz las revisiones tú: las instrucciones reducen los errores, no los eliminan.
¿TeamOnly escanea el código de mi app en busca de problemas de seguridad?
No. TeamOnly pone un inicio de sesión de la empresa delante de cada app, mantiene separados los datos y las claves de cada app, y deja las apps fuera de los buscadores. No revisa tu código, no escanea tus paquetes ni revisa las reglas dentro de tu app. Esos puntos de la checklist siguen siendo tuyos.
¿Qué debería revisar TI antes de aprobar una app hecha con IA?
Dónde está alojada y quién puede llegar a ella, cómo se restringe el inicio de sesión, dónde están las claves, qué datos guarda, quién es el responsable y qué pasa cuando esa persona se va. La sección “Para TI” de esta página es una revisión corta que puedes hacer en 15 minutos con el creador.
Deja que la plataforma cierre las puertas abiertas.
Publica con un comando y la app queda detrás del inicio de sesión de tu empresa, fuera de los buscadores, con su propia base de datos y sus secretos. Pruébalo gratis 14 días sin tarjeta.