Base de datos expuesta en el vibe coding: cómo evitarlo antes del go-live

Una base de datos puede estar expuesta incluso cuando la aplicación parece funcionar bien. La interfaz de usuario muestra solo los datos correctos, el inicio de sesión funciona, las API responden, el despliegue se realiza con éxito y el fundador puede hacer una demostración convincente. El riesgo surge en otro lugar: una cadena de conexión en el repositorio, una base de datos accesible desde internet, reglas demasiado permisivas, una copia de seguridad pública, un usuario con privilegios excesivos o un endpoint generado por IA que devuelve más datos de los previstos.

En el vibe coding, la base de datos llega pronto. Herramientas como Lovable, Bolt.new, Replit Agent, Cursor, Copilot, Codex y Claude Code ayudan a conectar tablas, almacenamiento, autenticación, API, paneles y despliegues en muy poco tiempo. Esta velocidad es útil, pero a menudo empuja hacia configuraciones que hacen que el MVP funcione de inmediato y posponen el endurecimiento (hardening). Para fundadores, PMs y desarrolladores junior, la pregunta antes de la beta no es solo “¿responde la base de datos?”, sino quién puede alcanzarla, con qué credenciales, desde qué entornos, a través de qué API, con qué reglas, qué copias de seguridad, qué exportaciones y qué datos reales.

[Callforaction-WAPT]

Base de datos expuesta no significa solo inyección SQL

Cuando se habla de una base de datos expuesta, muchos piensan inmediatamente en la inyección SQL. Es un riesgo importante, pero en las aplicaciones creadas con IA, la exposición suele surgir antes: configuración, credenciales, permisos, red, almacenamiento, copias de seguridad y API. Una base de datos puede estar protegida contra inyecciones y aun así exponer datos porque una política está abierta, una clave está en el cliente o un volcado (dump) terminó en un bucket público.

Los errores más comunes son prácticos: archivos .env subidos al repositorio, cadenas de conexión en los registros (logs), RLS deshabilitada, reglas de seguridad de Firebase permisivas, MongoDB accesible desde rangos de IP demasiado amplios, Postgres con acceso público innecesario, bases de datos de staging con datos reales, claves de servicio usadas desde el frontend, copias de seguridad descargables, exportaciones CSV sin proteger y rutas de depuración dejadas en línea. El problema no es la base de datos elegida —PostgreSQL, Supabase, Firebase, MongoDB Atlas, RDS, Cloud SQL, PlanetScale, Neon, Pinecone, pgvector o una base de datos autohospedada pueden usarse de forma segura—, sino publicar una aplicación antes de haber verificado cómo entra el dato, cómo se lee, cómo se copia y cómo puede salir.

Cadenas de conexión, archivos .env y credenciales en el lugar equivocado

La primera exposición suele ser una cadena de conexión. Durante el desarrollo con IA, el desarrollador pega una URL de base de datos en el chat, el agente genera un archivo .env, un ejemplo de despliegue termina en el README, un log imprime la configuración o una variable privada se coloca en el frontend para resolver un error. Una cadena de conexión puede contener host, base de datos, usuario, contraseña, parámetros TLS y privilegios: si termina en Git, prompts, tickets, logs, artefactos o paquetes, no basta con eliminarla del archivo, hay que rotarla. Incluso una credencial de staging puede ser crítica si ese entorno contiene datos reales o tiene acceso a recursos compartidos.

Antes del go-live, es necesario buscar URLs de bases de datos, contraseñas, claves de servicio, archivos .env, archivos .pem, volcados, copias de seguridad y credenciales CLI en repositorios, historial de Git, ramas, etiquetas, logs de CI/CD, prompts, incidencias y artefactos. El siguiente paso es separar las claves de desarrollo, staging y producción: una clave utilizada por el agente o en una demo nunca debería poder leer la base de datos real.

Base de datos accesible desde internet

Muchas bases de datos en la nube nacen con un endpoint accesible. A veces es necesario; a menudo es solo cómodo. Si la base de datos acepta conexiones desde rangos de IP amplios, desde todo internet o desde redes no controladas, las contraseñas y los secretos se convierten en la única barrera, lo cual es insuficiente para un entorno de producción. Para un MVP, esto sucede cuando el equipo necesita conectar rápidamente la aplicación, el panel de control, herramientas locales y el despliegue.

Es importante controlar el acceso a la red, listas de permitidos (allowlist) de IP, grupos de seguridad, firewalls, VPC, redes privadas y reglas de conexión. En PostgreSQL autohospedado, parámetros como listen_addresses y pg_hba.conf deciden desde dónde se puede entrar; en MongoDB Atlas, la lista de acceso IP es un control clave; en entornos en la nube, los grupos de seguridad y las rutas de red deben ser coherentes con la arquitectura real. Una base de datos de producción no debería ser accesible desde cada entorno temporal, despliegue de vista previa o portátil personal sin necesidad: si se requiere acceso administrativo, es preferible utilizar canales controlados como bastiones, VPN, puntos finales privados o acceso temporal.

Reglas permisivas en Supabase, Firebase y BaaS

Las plataformas BaaS aceleran mucho el desarrollo, pero la seguridad depende de las reglas. Supabase requiere Row Level Security (RLS) y políticas coherentes para aislar usuarios y clientes (tenants); Firebase utiliza reglas de seguridad para Firestore, Realtime Database y Storage. Si la IA genera una regla abierta para que la demo funcione, el proveedor sigue siendo robusto, pero el dato puede salir.

En Supabase, una tabla con datos privados no debería tener políticas genéricas o carecer de RLS. La clave anónima (anon key) puede estar en el cliente solo si RLS y las políticas limitan realmente lo que el cliente puede leer y escribir, mientras que la clave de rol de servicio (service role key) debe mantenerse fuera del frontend, de los logs y del repositorio. En Firebase, reglas como allow read, write: if true o controles basados solo en request.auth != null pueden ser demasiado amplios. Antes del go-live, es útil probar la lectura y escritura con diferentes usuarios, datos de diferentes clientes, token ausente, token caducado y solicitudes directas, sin confiar en que la interfaz de usuario muestre solo los registros correctos.

Usuarios de base de datos con demasiados privilegios

Una aplicación no debería conectarse a la base de datos con un usuario administrativo si no es necesario. Sin embargo, en el vibe coding, la IA puede sugerir la credencial que “resuelve” el error de permisos —superusuario, propietario de la base de datos, rol de servicio, cuenta con acceso a todas las tablas, clave con privilegios globales—, haciendo que cada error sea más costoso. Si la aplicación tiene inyección SQL, SSRF, RCE, fuga de logs o un endpoint vulnerable, el atacante hereda privilegios demasiado amplios. Incluso sin un ataque externo, un agente de IA con acceso a terminal o herramientas de base de datos puede realizar operaciones que no deberían estar en su perímetro.

El control correcto es el principio de menor privilegio. Esto significa utilizar usuarios separados para la aplicación, migraciones, trabajos de mantenimiento, lectura de analíticas y administración, limitando los permisos a tablas, esquemas y operaciones necesarias, y evitando usuarios en tiempo de ejecución con permisos de DROP, ALTER, privilegios globales o acceso a datos fuera de su perímetro.

Copias de seguridad, volcados y exportaciones expuestos

A menudo, la base de datos operativa está más protegida que sus copias. Los volcados SQL, exportaciones CSV, instantáneas (snapshots), copias de seguridad automáticas, archivos temporales, informes, artefactos de tuberías (pipelines) y carpetas de soporte pueden contener todo el patrimonio de datos. En un MVP, estos archivos se crean para depuración, migración, demostración o pruebas y luego se olvidan en buckets en la nube, almacenamiento BaaS, repositorios, entornos de staging, portátiles, sistemas de tickets, correos electrónicos, CI/CD, imágenes de contenedores o carpetas temporales.

Las copias de seguridad y los volcados deben tener accesos limitados, cifrado donde sea apropiado, retención definida, registro de accesos y separación de los activos públicos. Un volcado real en staging puede estar más expuesto que en producción, y una exportación CSV generada por una ruta de administración puede ser descargable sin controles adecuados. Si una copia contiene datos reales, debe tratarse como producción.

API generadas que exponen la base de datos

Incluso cuando la base de datos no es directamente pública, las API pueden exponerla. Un agente puede generar endpoints CRUD, rutas de administración, funciones de búsqueda, exportaciones, depuración, filtros, informes o paneles que leen datos sin autorización suficiente, convirtiendo de hecho el endpoint en la base de datos expuesta.

Ejemplos frecuentes: /api/users devuelve todos los usuarios, /api/orders?user_id=... acepta ID del cliente sin verificación, /api/export produce un CSV completo, /api/debug/db permanece activo en producción, una ruta de administración solo verifica el inicio de sesión, una búsqueda global ignora clientes y roles, una función serverless usa la clave de servicio y no filtra los resultados. Antes del go-live, es necesario hacer un inventario de las rutas que leen de la base de datos y probar llamadas directas, parámetros manipulados, tokens faltantes, roles bajos, clientes diferentes y métodos HTTP no previstos. Si un endpoint devuelve datos que la interfaz de usuario no mostraría, la base de datos está expuesta a través de la aplicación.

Almacenamiento, buckets y metadatos vinculados a la base de datos

Muchas aplicaciones asocian registros de bases de datos con archivos: documentos, imágenes, archivos adjuntos, facturas, avatares, contratos, informes, exportaciones, conjuntos de datos. Si la base de datos contiene solo la ruta pero el bucket es público, la protección del registro no es suficiente; si la URL es predecible, un usuario puede descargar archivos de otros incluso sin consultar la base de datos.

Es necesario verificar buckets, rutas, URL firmadas, duración de los enlaces, políticas por usuario o cliente, vistas previas, miniaturas, texto extraído y metadatos. Un archivo puede ser privado pero tener una vista previa pública, un nombre de archivo puede revelar información del cliente y una exportación puede guardarse en el almacenamiento y permanecer accesible después de la fecha de vencimiento prevista. La prueba práctica es sencilla: cargar archivos con dos usuarios diferentes, luego intentar descargar y eliminar de forma cruzada cambiando el ID, la ruta o el nombre del archivo. Si la aplicación utiliza Supabase Storage, Firebase Storage, S3 o similares, el control debe incluir tanto las políticas de almacenamiento como la lógica de la aplicación.

Staging, vista previa y datos reales

Uno de los errores más comunes es utilizar datos reales fuera de producción. El equipo copia un volcado para depuración, conecta un despliegue de vista previa a la base de datos real, utiliza las mismas claves en staging, importa clientes para una demo o prueba un agente con datos reales. Estos entornos suelen tener menos controles, más personas con acceso y logs más detallados.

La separación dev/staging/prod debe incluir bases de datos, almacenamiento, claves, usuarios, callbacks, copias de seguridad y herramientas de observabilidad. Si se necesitan datos realistas, es preferible utilizar conjuntos de datos sintéticos, enmascaramiento o subconjuntos minimizados, evitando que las URL de vista previa, ramas temporales o entornos generados por IA apunten a la base de datos real. Cuando una base de datos de staging contiene datos reales, debe tratarse como producción: accesos limitados, copias de seguridad protegidas, registro de actividad, retención, parches y control de credenciales.

Vector database, RAG y fuga de documentos

Las aplicaciones de IA que utilizan RAG añaden otra forma de base de datos: almacenes vectoriales, almacenes de incrustaciones (embeddings), índices de documentos. ChromaDB, Pinecone, pgvector y otros sistemas pueden contener fragmentos de documentos, tickets, correos electrónicos, contratos, manuales, bases de conocimiento y datos de clientes. Si la recuperación (retrieval) no aplica autorización, un usuario puede recibir contexto que pertenece a otros.

La seguridad de la base de datos vectorial no se limita al motor de la base de datos, sino que requiere controlar qué se indexa, con qué metadatos, en qué espacio de nombres o cliente, quién puede recuperarlo, qué filtros se aplican antes de la recuperación y qué documentos terminan en los logs o en el prompt del modelo. Para aplicaciones multi-cliente, es necesario separar espacios de nombres o aplicar filtros de autorización robustos, registrar qué documentos se recuperan y prever la eliminación y reindexación cuando un usuario elimina datos o cambia permisos. Si el modelo recibe documentos no autorizados, la respuesta ya puede haber expuesto el dato.

Agentes de IA con acceso a la base de datos

Cuando un agente puede usar terminal, MCP, herramientas SQL, paneles en la nube o credenciales en tiempo de ejecución, la base de datos se convierte en parte de su perímetro operativo. El riesgo no es solo que el agente genere código incorrecto: puede ejecutar consultas, modificar datos, lanzar migraciones, leer tablas o imprimir resultados en chats y logs.

No le des a un agente credenciales de producción si no es estrictamente necesario. Es preferible utilizar bases de datos sandbox, datos sintéticos, usuarios de solo lectura, permisos temporales y aprobación para comandos destructivos. Si el agente debe generar migraciones, es conveniente revisarlas antes de aplicarlas; si debe consultar datos, es necesario limitar las tablas y filas disponibles. Para agentes conectados a través de MCP o herramientas externas, es necesario mapear qué acciones son posibles —leer, escribir, eliminar, exportar, crear usuarios, modificar esquemas, acceder a gestores de secretos— y aplicar el principio de menor privilegio: el agente debe tener solo lo que necesita para la tarea, no todo lo que es cómodo.

Qué verificar antes de la beta

Antes de abrir una beta o importar datos reales, es útil preparar un inventario de los datos: qué bases de datos existen, qué entornos las utilizan, qué usuarios y claves acceden, qué API leen o escriben, qué copias de seguridad están activas, qué buckets contienen archivos vinculados a los registros, qué agentes o tuberías tienen credenciales.

Luego es necesario realizar pruebas prácticas: escaneo de secretos en repositorios e historial, control de red, verificación de políticas, acceso con usuario de privilegios mínimos, pruebas de API en exportaciones y rutas de depuración, descarga de archivos con diferentes usuarios, búsqueda de volcados y copias de seguridad en artefactos, control de staging y vista previa. Estos pasos encuentran problemas que una demo no muestra.

Señales de que la base de datos ya está demasiado expuesta

Algunas señales merecen atención inmediata incluso si aún no se ha encontrado una violación: un archivo .env subido al repositorio, una cadena de conexión en un log, una base de datos que acepta conexiones desde IP no reconocidas, una copia de seguridad en un bucket compartido, un panel de administración accesible fuera de la red prevista, un despliegue de vista previa con datos reales, una exportación CSV con más columnas de las necesarias.

Otras señales surgen del comportamiento de la aplicación: una consulta de lista devuelve registros de todos los usuarios y luego la interfaz de usuario filtra en el lado del cliente, un endpoint acepta limit=100000 y produce exportaciones completas, una función de búsqueda devuelve resultados entre clientes, un usuario de base de datos utilizado por la aplicación puede leer tablas que ninguna función utiliza, un agente de IA puede ejecutar consultas en producción para ayudar en la depuración. Estas señales no son todas incidentes, pero indican que el perímetro de datos no está gobernado. Antes de conectar usuarios reales, vale la pena detenerse y reconstruir el camino del dato: entrada, consulta, API, almacenamiento, logs, copias de seguridad, exportación y eliminación.

Qué corregir antes y qué planificar

La prioridad debe darse a todo lo que permita el acceso directo o la copia masiva de datos. Cadenas de conexión de producción expuestas, bases de datos alcanzables desde redes no previstas, copias de seguridad públicas, claves de servicio en el frontend, usuarios de base de datos administrativos utilizados por la aplicación, exportaciones sin autorización y reglas abiertas sobre datos privados deben corregirse antes del go-live.

La remediación debe cerrar el riesgo, no solo ocultarlo. Si una cadena de conexión ha salido, hay que rotar la credencial y revisar los logs de acceso. Si una base de datos era accesible desde internet, es necesario restringir la red y verificar quién se ha conectado. Si una copia de seguridad era pública, hay que eliminar el acceso, rotar cualquier clave incluida y evaluar qué contenía. Si una política estaba abierta, es necesario añadir pruebas negativas con diferentes usuarios y clientes.

Otras mejoras pueden planificarse con responsables y fechas límite: fortalecer el nombrado de variables, automatizar el escaneo de secretos, documentar los usuarios de DB, reducir la retención, mejorar las alertas, separar mejor staging y producción. Sin embargo, la protección de la base de datos y sus copias debe tratarse como un requisito de publicación, no como un acabado posterior.

Cómo ISGroup puede verificar bases de datos, almacenamiento y API

ISGroup puede verificar si una aplicación creada con IA expone la base de datos a través de configuraciones, credenciales, superficies en línea, API, copias de seguridad, almacenamiento o la nube. El control comienza desde la forma real en que se accede al dato: red, aplicación, BaaS, almacenamiento, tuberías y agentes.

Si el proyecto tiene…	Riesgo principal	Control recomendado
Bases de datos, hosts, servicios, paneles o endpoints alcanzables	Exposiciones técnicas y configuraciones conocidas	Vulnerability Assessment
Web apps, API, exportaciones, cargas o rutas que leen datos	Abuso de aplicaciones y acceso no autorizado	Web Application Penetration Testing
Bases de datos en la nube, buckets, IAM, grupos de seguridad, VPC, BaaS o copias de seguridad	Configuraciones erróneas en la nube o privilegios excesivos	Cloud Security Assessment
Cadenas de conexión, consultas, políticas, usuarios de DB o lógica del lado del servidor en el código	Errores de implementación y secretos en el código	Code Review
Codificación con IA utilizada de forma continua en bases de datos, migraciones y despliegues	Controles no repetibles en las versiones	Software Assurance Lifecycle

La elección del control depende de por dónde puede salir el dato: base de datos alcanzable, API vulnerable, copia de seguridad expuesta, bucket público, clave en el código o agente con permisos excesivos. Antes de la beta, conviene delimitar estos caminos y cerrar las exposiciones más críticas.

¿Has creado una aplicación con IA y estás a punto de conectarla a datos reales? ISGroup puede verificar bases de datos, almacenamiento, API, credenciales, copias de seguridad, reglas y configuraciones antes de que el MVP se convierta en un riesgo operativo.

Evidencias a preparar

Para iniciar una verificación, es útil preparar una lista de bases de datos, proveedores, entornos, cadenas de conexión gestionadas, usuarios de DB, roles, políticas, copias de seguridad, almacenamiento, API, repositorios, tuberías, agentes utilizados y partes generadas con IA. Si se utiliza un BaaS, es necesario incluir el proyecto de Supabase o Firebase con reglas, buckets y claves; si se utiliza una base de datos en la nube, incluir red, grupos de seguridad, lista de permitidos de IP, VPC y cuentas de servicio.

También se necesitan datos de prueba: dos usuarios, dos clientes si están presentes, registros similares, archivos cargados, exportaciones, copias de seguridad y cuentas con diferentes privilegios. Sin estos elementos, es difícil demostrar si la aplicación realmente aísla los datos y las copias. Si ya se han recibido alertas sobre secretos, reglas permisivas, bases de datos públicas, buckets abiertos o volcados compartidos, es conveniente incluirlos: a menudo, una sola alerta revela un proceso que debe corregirse antes del go-live.

Decisión antes del go-live

Bloquea el go-live si encuentras cadenas de conexión de producción expuestas, bases de datos alcanzables desde redes no previstas, RLS o reglas de seguridad abiertas sobre datos privados, usuarios de base de datos con demasiados privilegios, copias de seguridad o volcados descargables, buckets públicos con documentos privados, API que exportan datos sin autorización o agentes con credenciales de producción no controladas.

Solo puedes planificar después del lanzamiento las mejoras con riesgo residual claro: documentación, alertas adicionales, reducción progresiva de privilegios no críticos, nombrado de claves, automatización de controles. La protección del dato operativo debe cerrarse antes de utilizar clientes, pagos, documentos o información corporativa.

Lista de verificación de base de datos expuesta

Busca cadenas de conexión y credenciales en código, archivos .env, historial, prompts, logs y artefactos.
Verifica listas de permitidos de IP, firewalls, grupos de seguridad, VPC y acceso administrativo.
Controla RLS, reglas de seguridad, ACL y políticas en tablas y almacenamiento.
Usa usuarios de DB con privilegios mínimos, separados por entorno.
Protege copias de seguridad, volcados, instantáneas, exportaciones e informes.
Prueba API, rutas de depuración, exportaciones y paneles que leen de la base de datos.
Verifica buckets, URL firmadas, vistas previas y metadatos vinculados a los registros.
Evita datos reales en staging, vista previa y entornos de agentes.
Aísla bases de datos vectoriales y recuperación por usuario o cliente.
Limita agentes de IA y herramientas MCP con acceso a la base de datos.

Preguntas frecuentes

¿Base de datos expuesta significa necesariamente acceso público directo?
No. También puede significar cadena de conexión expuesta, copia de seguridad descargable, API demasiado permisiva, bucket público, RLS deshabilitada, staging con datos reales o base de datos vectorial sin aislamiento.
Si la base de datos no es pública, ¿estoy a salvo?
No necesariamente. El dato puede salir a través de API, exportaciones, logs, copias de seguridad, almacenamiento, credenciales en el código o agentes con acceso a la base de datos.
¿Qué diferencia hay entre Vulnerability Assessment y Web Application Penetration Testing en este caso?
El Vulnerability Assessment ayuda a mapear servicios y configuraciones expuestas. El WAPT prueba si la aplicación y la API permiten leer o modificar datos de forma abusiva.
¿Supabase o Firebase evitan el problema?
Ofrecen controles útiles, pero RLS, reglas de seguridad, buckets, claves, usuarios y separación de entornos deben configurarse y probarse en el proyecto real.
¿Deben protegerse las copias de seguridad como la base de datos?
Sí. A menudo contienen más datos que la base de datos operativa y están menos monitoreadas. Los volcados, instantáneas y exportaciones con datos reales deben tener accesos, retención y almacenamiento controlados.
¿Qué cambia con una base de datos vectorial?
El dato puede recuperarse como contexto del modelo. Si los filtros, espacios de nombres o el aislamiento de clientes no funcionan, un usuario puede recibir información indexada de documentos de otros.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

Supabase Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
Supabase Hardening Data API: https://supabase.com/docs/guides/database/hardening-data-api
Supabase Securing your API: https://supabase.com/docs/guides/api/securing-your-api
Firebase Security Rules: https://firebase.google.com/docs/rules/
Firebase Realtime Database Security Rules: https://firebase.google.com/docs/database/security
MongoDB Atlas IP Access List: https://www.mongodb.com/docs/atlas/security/ip-access-list/
PostgreSQL Connections and Authentication: https://www.postgresql.org/docs/current/runtime-config-connection.html
Pinecone multitenancy: https://docs.pinecone.io/guides/get-started/implement-multitenancy
OWASP API Security: https://owasp.org/www-project-api-security/
OWASP Top 10 for LLM Applications: https://genai.owasp.org/llm-top-10/