Miles de bases de datos de Supabase están abiertas ahora mismo. Cualquiera con el enlace correcto puede leerlas sin que el dueño se entere. No es un caso aislado: hay investigadores de seguridad que salieron a probar esto y llegaron a cientos, incluso miles, de proyectos expuestos por el mismo error de configuración. Y ese es solo 1 de los 4 puntos que un agente de IA casi nunca revisa por su cuenta cuando te ayuda a construir algo.
Vibecodear con IA te da velocidad. Te construye la base de datos, el backend, la automatización, todo en minutos. Lo que no te dice es que "funciona" y "es seguro" son 2 cosas distintas, y la IA optimiza para la primera. Aquí están los 4 puntos que se quedan sin revisar y cómo cerrarlos esta semana.
Supabase te da una casa con la puerta sin cerradura.
Cada tabla que creas es una casa. Si no le pones cerradura, entra cualquiera que sepa la dirección. A esa cerradura se le llama RLS: Row Level Security, seguridad a nivel de fila. Es la regla que decide quién puede leer, escribir o eliminar datos de cada tabla.
Supabase convierte automáticamente tu base de datos en una API REST. Eso es maravilloso para ir rápido, y es exactamente el problema: sin RLS, esa API le entrega los datos completos a quien pregunte. Investigadores que salieron a probar esto encontraron endpoints donde una sola consulta devolvía los primeros 100 usuarios de una tabla privada, o la lista completa de proyectos que debían ser privados. No hackearon nada. Solo preguntaron.
La IA no activa esto por ti. Te crea la tabla, te arma las consultas, hace que todo funcione en el navegador... y se detiene ahí.
Qué hacer: activa RLS en cada tabla de Supabase apenas la crees, no al final del proyecto.
Prueba esto con tu agente de IA
Revisa cada tabla de mi proyecto en Supabase y dime cuáles tienen RLS desactivado. Para cada una, dime qué política necesitaría y por qué. No cambies nada todavía.
Usar IA es pagar por tokens. Cuantas más personas usan tu programa, más tokens se consumen y más sube la factura.
El problema no es solo un pico de tráfico normal. Es un loop mal escrito, un bug que llama a la IA en un ciclo infinito, o alguien probando los límites de tu API a propósito. Sin un tope, esa factura no tiene techo.
La mayoría de las plataformas traen este límite desactivado por defecto. Está ahí, pero tienes que ir a buscarlo y activarlo tú mismo. La IA que te ayudó a montar la integración no te lo activa, porque no es parte de "hacer que funcione": es una decisión sobre cuánto estás dispuesto a arriesgar.
Qué hacer: entra a la configuración de facturación de la IA que uses y pon un tope de gasto explícito, incluso si hoy es bajo. Prefieres que el servicio se detenga a que la factura se dispare mientras duermes.
Tener copias de seguridad no significa que funcionen. Un backup que nunca restauraste es una teoría, no una copia de seguridad.
Es el punto ciego más silencioso de los 4 porque no falla hasta el peor momento posible: cuando ya perdiste los datos originales y necesitas el backup para recuperarlos, y ahí descubres que estaba corrupto, incompleto o apuntaba a la base de datos equivocada.
La IA puede configurarte backups automáticos sin problema. Lo que no hace sola es la parte incómoda: bajar ese backup, restaurarlo en un entorno de prueba y confirmar que los datos que salen son los datos que esperabas. Eso requiere que alguien decida hacerlo, y normalmente nadie lo prioriza hasta que ya es tarde.
Qué hacer: haz una prueba de restauración real, no solo revisar que el backup "se generó". Una vez al mes o al trimestre, toma el backup más reciente, restáuralo aparte y verifica que los datos estén completos y correctos.
Una librería que instalas hoy no es la misma librería para siempre.
El paquete puede seguir teniendo el mismo nombre, la misma versión mayor, la misma promesa en su documentación, y aun así cambiar de manos. Un desarrollador vende o abandona el proyecto, otra persona toma el control, y una actualización menor mete código que no tiene nada que ver con lo que el paquete hacía antes.
La IA instala dependencias constantemente. Ninguna herramienta que use por defecto te avisa "esta librería cambió de dueño la semana pasada" o "esta actualización agregó código que no coincide con el resto del historial". Confía en que el registro del paquete (npm, PyPI, el que sea) hizo su trabajo de verificación, y ese registro no siempre lo hace.
Qué hacer: antes de aceptar una actualización, sobre todo en librerías que tocan datos sensibles o pagos, revisa qué cambió. Mira si cambió la persona que estaba a cargo de la librería y si el changelog explica lo que realmente se modificó en el código.
Antes de publicar cualquier proyecto, pídele algo así:
Revisa mis cambios pendientes: dime en qué tablas de Supabase falta RLS, si hay algún límite de gasto sin configurar en los servicios que uso, cuándo fue la última vez que probé restaurar un backup y si alguna dependencia cambió recientemente. No arregles nada todavía, solo dame la lista.
