¿Tu App Vibe-Coded Está Filtrando Datos y Drenando Tu Presupuesto?

Abres tu panel la mañana después del lanzamiento esperando a tus primeros usuarios. En cambio, encuentras una factura cloud con tres ceros de más, o peor, un mensaje de un desconocido diciéndote que toda tu tabla de usuarios está en un canal público de Telegram.

Esto ya no es una historia de terror poco común. Es el modo de fallo silencioso y recurrente del “vibe coding”: construir productos reales mediante prompts a herramientas de IA como Claude Code, Cursor y Windsurf hasta que la interfaz se ve bien y la función funciona. Estas herramientas son realmente excelentes escribiendo código funcional rápido. Lo que no hacen bien automáticamente es pensar como un ingeniero de seguridad, porque nunca se lo pediste.

La interfaz puede parecer lista para producción mientras la arquitectura de debajo está completamente abierta. A continuación, cinco errores que vemos más a menudo cuando las bases de código asistidas por IA se encuentran con el internet real, por qué cada uno se vuelve caro rápidamente, y exactamente cómo cerrarlos antes de publicar.

La parte incómoda: ninguno de estos cinco errores requiere un hacker. Un visitante curioso que pulsa F12 en su navegador, un bot aburrido que escanea dominios al azar, o una sola pestaña en segundo plano olvidada es suficiente para desencadenar cualquiera de ellos. Eso es lo que los hace tan comunes, y tan evitables, en las bases de código generadas por IA.

Por Qué las Apps Vibe-Coded Reciben Golpes Más Duros que las Construidas Tradicionalmente

Cuando un desarrollador escribe a mano una integración de API, la seguridad es una decisión consciente tomada en el momento: “¿esta clave debería vivir en el servidor o en el cliente?” Cuando un asistente de IA escribe el mismo código, optimiza para “¿funciona cuando lo pruebo?”, no para “¿aguanta cuando un desconocido lo inspecciona?”.

Esa diferencia es todo el problema. El código generado por IA funciona bien en vista previa, bien en tu demo al cliente, y sigue funcionando bien hasta el lanzamiento, cuando alguien ejecuta una comprobación de cinco segundos usando nada más que la consola F12 de su navegador.

Error 1: Claves API Hardcodeadas en Tu Código Frontend

Esta es la forma más común en que un fundador en etapa temprana se despierta con una cuenta de OpenAI o Anthropic drenada.

Pide a un asistente de IA que “se conecte a la API de OpenAI” o “añada un cliente de Supabase”, y a menudo escribirá la clave directamente en un componente de React, una página de Next.js, o un archivo .js del lado del cliente, porque es la forma más rápida de hacer funcionar la función. Compila. Funciona en vista previa. Lo lanzas.

El problema es que todo lo que se envía al navegador es descargable por cualquiera que visite tu sitio. Un visitante pulsa F12, abre la pestaña Sources o Network, y tu clave sk-... o tu clave service_role de Supabase está ahí mismo, en texto plano. Una sola clave expuesta suele ser todo lo que se necesita para drenar todo un presupuesto mensual de IA en minutos, y si es tu clave service_role, el atacante puede saltarse cada permiso que tu base de datos debía hacer cumplir.

Cómo arreglarlo de verdad:

• Nunca llames a una API de pago o privilegiada directamente desde código del lado del cliente. Enrútala a través de un endpoint backend o una función serverless que controles tú.
• Almacena los secretos reales en variables de entorno del lado del servidor, nunca en nada que se empaquete en el build del frontend. En Supabase, solo la clave pública anon pertenece al código frontend.
• Rota cualquier clave de inmediato si descubres que estuvo expuesta alguna vez, aunque sea brevemente, en un repositorio público o en un paquete desplegado.

Error 2: Row Level Security Dejado Deshabilitado en Supabase o Firebase

Este es el error que convierte “tuvimos un bug” en “tuvimos una brecha de datos”.

Supabase y Firebase te dan a ambos una base de datos real directamente accesible desde el navegador, lo cual es poderoso para construir rápido. Pero ese poder viene con una condición: Row Level Security (RLS) tiene que estar configurado para decir quién puede leer y escribir qué filas. Los asistentes de codificación con IA frecuentemente te guían por la configuración con RLS dejado en un estado permisivo o completamente público, porque una política pública es la forma más rápida de hacer que tu función “simplemente funcione” durante el desarrollo.

El problema es que una política RLS pública no solo significa que los usuarios conectados pueden leer más de lo que deberían. Significa que cualquiera, sin ningún inicio de sesión, puede abrir una consola del navegador y extraer cada fila de cada tabla expuesta disparando una petición fetch en bruto directamente a la URL pública de la API de tu base de datos. Toda tu lista de usuarios, cada pedido, cada mensaje privado, todo recuperable con una petición que tarda menos tiempo en escribirse que esta frase.

Cómo arreglarlo de verdad:

• Trata el RLS como obligatorio, no opcional, antes de que datos de usuarios reales entren en la base de datos. Actívalo en cada tabla que no esté destinada a ser completamente pública.
• Escribe políticas limitadas a auth.uid() (Supabase) o la comprobación autenticada equivalente (Firebase), para que un usuario solo pueda tocar sus propias filas.
• Prueba las políticas como una petición anónima y no autenticada, no solo desde tu propia sesión de navegador conectada donde podrías tener accesos elevados sin darte cuenta.
• Revisa el RLS de nuevo cada vez que se añada una nueva tabla, ya que no queda automáticamente cubierta por las reglas que escribiste para otras tablas.

Cubrimos el proceso de decisión práctico para esto con más profundidad en nuestra guía sobre cuándo añadir row-level security a un MVP SaaS de Supabase, incluyendo cómo introducirlo por fases sin bloquear la velocidad de desarrollo temprana.

Error 3: Bucles de Renderizado Infinitos que Consumen Silenciosamente Peticiones API

Este no parece al principio un error de seguridad. Parece un error de facturación, y para cuando te das cuenta, el daño ya está en tu factura.

El hook useEffect de React se vuelve a ejecutar cada vez que algo cambia en su array de dependencias. Los asistentes de IA a veces se equivocan con ese array: un objeto o función se recrea en cada renderizado, el efecto se dispara de nuevo, eso provoca una actualización de estado, lo que causa otro renderizado, lo que dispara el efecto de nuevo. El bucle se repite tan rápido como el navegador puede ejecutarlo.

Si ese efecto contiene por casualidad una llamada API, una consulta a Supabase, o una llamada a un modelo de IA de pago, no obtienes una petición por carga de página. Obtienes cientos o miles, a menudo desde una sola pestaña que un solo usuario olvidó abierta en segundo plano durante la noche.

Caso real: una sola pestaña de navegador inactiva generó más de 2.000 peticiones API antes de que alguien lo notara, simplemente porque un array de dependencias de useEffect hacía referencia a un objeto recién creado en cada renderizado en lugar de a un valor estable. Multiplica eso por un puñado de pestañas olvidadas entre tus primeros usuarios, y un pequeño error se convierte en una factura que tienes que explicar a un cofundador.

Cómo arreglarlo de verdad:

• Especifica siempre un array de dependencias completo y correcto para cada useEffect — las dependencias faltantes y las referencias inestables (nuevos objetos, arrays o funciones creados en línea) son las dos causas más comunes de este bucle.
• Usa la pestaña Network de tu navegador durante las pruebas y observa un recuento de peticiones que sigue subiendo en una página con la que no estás interactuando activamente.
• Añade rate limiting o monitorización del recuento de peticiones en cualquier endpoint que toque una API de pago de terceros, para que un bucle frontend descontrolado choque contra un muro en lugar de contra una factura abierta.
• Configura alertas de uso y límites de gasto estrictos directamente en los paneles de OpenAI, Anthropic y tu proveedor cloud. Esto no detendrá el error, pero evitará que el error se convierta en una sorpresa de 1000€.

Error 4: Rutas Admin e Internas Lanzadas Sin Autenticación Real

Este error se esconde a plena vista porque la función funciona perfectamente para ti, la única persona que sabe que la URL existe.

Pide a un asistente de IA “un panel admin para gestionar usuarios” o “una API interna para actualizar el estado de pedidos”, y a menudo construirá la página correctamente mientras se salta la comprobación de autenticación, porque nunca la pediste explícitamente. El resultado es una ruta /admin, /internal-api, o /debug totalmente funcional en tu dominio de producción sin ninguna puerta de inicio de sesión, confiando en que nadie adivine la URL.

La oscuridad no es seguridad. Los bots automatizados rastrean rutinariamente rutas comunes como /admin, /api/internal, y /.env en cada dominio que encuentran, sin ninguna idea de qué hace tu producto. Si la ruta responde sin preguntar quién pregunta, eventualmente será encontrada, y quien la encuentre obtiene el mismo acceso que tú.

Cómo arreglarlo de verdad:

• Exige autenticación y comprobaciones de rol en cada ruta que no esté destinada a ser completamente pública, incluidas las que construiste “solo para ti mismo” durante el desarrollo.
• Nunca confíes en una URL no listada o difícil de adivinar como tu única protección, trata cada ruta como descubrible.
• Prueba cada ruta admin e interna de la misma manera que probaste el RLS: como una petición desconectada y no autenticada, no desde tu propia sesión de navegador ya conectada.
• Pregunta directamente a tu asistente de IA: “¿esta ruta comprueba autenticación y rol antes de devolver datos?”, en lugar de asumir que lo hace.

Error 5: Sin Rate Limiting en Endpoints de Pago o Sensibles

Este es el error que convierte a un visitante curioso, o a un bot que encontró tu API por accidente, en tu mayor partida de gasto del mes.

Incluso con claves aseguradas y RLS habilitado, un endpoint que acepta peticiones ilimitadas de fuentes ilimitadas sigue siendo un grifo abierto. El código backend generado por IA se entrega con frecuencia funcional pero sin regular: un endpoint que llama a un modelo de IA de pago o escribe en tu base de datos procesará cada petición que reciba, tan rápido como la reciba, sin ningún concepto de “demasiado, demasiado rápido” a menos que alguien lo haya construido explícitamente.

A diferencia del bucle useEffect descontrolado (un error accidental en tu propio frontend), este riesgo viene de fuera: un scraper o un bot que machaca tu endpoint público a propósito, precisamente porque nada lo detiene.

Cómo arreglarlo de verdad:

• Añade rate limiting a nivel de endpoint o de puerta de enlace de API para cualquier ruta que te cueste dinero por llamada o toque datos sensibles, limitando peticiones por IP o por usuario dentro de una ventana de tiempo.
• Exige autenticación antes de que se ejecute una operación costosa; una petición no autenticada nunca debería poder disparar una llamada de IA de pago o una escritura masiva en la base de datos.
• Usa la limitación integrada de tu plataforma de hosting o puerta de enlace de API (Vercel, Cloudflare, Supabase Edge Functions, y puertas de enlace de API como Kong o AWS API Gateway lo soportan todas) en lugar de intentar construirlo tú mismo.
• Monitoriza picos de peticiones desde una sola IP o ID de usuario; un pico repentino y sostenido es una señal que merece una alerta, no solo una línea de facturación que notas después.

Comparación Rápida: Lo Que Realmente Te Cuesta Cada Error

Error	Qué Se Expone	Desencadenante Típico	Solución Más Rápida
Claves API hardcodeadas	Créditos de IA/API, uso de pago	Clave pegada en código frontend por el asistente de IA	Mover las llamadas a un endpoint backend, rotar la clave
Row Level Security deshabilitado	Contenido completo de la base de datos	Política RLS pública/permisiva que quedó de la configuración	Habilitar RLS, limitar políticas a auth.uid()
Bucles useEffect infinitos	Facturación cloud/API	Array de dependencias faltante o inestable	Corregir array de dependencias, añadir límites de tasa y de gasto
Rutas admin/internas sin autenticar	Acceso admin completo, datos internos	Ruta construida sin comprobación de autenticación	Añadir comprobaciones de autenticación y rol a cada ruta
Sin rate limiting en endpoints de pago	Facturación cloud/API, carga de base de datos	Endpoint dejado abierto a peticiones ilimitadas	Añadir rate limiting y exigir autenticación antes de llamadas costosas

La Autoauditoría de 5 Minutos que Puedes Hacer Ahora Mismo

No necesitas un equipo de seguridad para detectar la mayoría de esto. Antes de tu próximo despliegue, revisa estas comprobaciones tú mismo:

• Abre las DevTools en tu sitio en producción (F12 → pestaña Sources o Network) y busca sk-, service_role, o cualquier cadena que parezca una URL de conexión a base de datos. Si encuentras una, rótala de inmediato y mueve esa llamada al servidor.
• Abre tu panel de Supabase o Firebase y comprueba el estado del RLS en cada tabla. Cualquier cosa que muestre “public” o “disabled” junto a una tabla con datos reales de usuarios es una tabla que cualquiera puede consultar ahora mismo.
• Abre tu pestaña Network en una página con un useEffect y déjala inactiva durante 30 segundos. Si el recuento de peticiones sigue subiendo sin que hagas clic en nada, tienes un bucle, no una función.
• Revisa tus paneles de facturación de OpenAI, Anthropic y cloud en busca de alertas de uso. Si no has establecido un límite de gasto estricto, hazlo antes de terminar de leer esta frase, no después.
• Intenta cargar tus rutas admin, internas o de depuración en una ventana de incógnito estando desconectado. Si todavía puedes ver la página u obtener datos de ella, esa ruta no tiene autenticación real.
• Comprueba si tus endpoints de pago o sensibles tienen algún rate limiting configurado. Si un script pudiera llamar al mismo endpoint 10.000 veces seguidas sin ser ralentizado o bloqueado, es que no lo tiene.

Cinco minutos ahora salen más baratos que cualquier escenario que describe este artículo.

Esto No Es una Razón para Dejar de Usar Herramientas de Codificación con IA

Nada de esto significa que Claude Code, Cursor, o Windsurf sean herramientas inseguras, o que se deba evitar el desarrollo asistido por IA. Son genuinamente capaces de producir código de calidad de producción, incluidos patrones seguros, cuando la persona que las dirige revisa las cosas correctas. Las herramientas no son el punto de fallo. Lanzar sin una revisión enfocada en seguridad sí lo es.

Trata cada función generada por IA como tratarías una pull request de un desarrollador junior: probablemente está bien, pero merece un segundo par de ojos sobre cualquier cosa que toque secretos, permisos de base de datos, o llamadas API de pago antes de que se ponga en producción. Esa revisión toma una tarde. Una factura de 1000€ o una base de datos filtrada tardan mucho más en limpiarse, y pueden costar mucho más que dinero una vez que la confianza del cliente está en juego.

Si ya estás inmerso en una build vibe-coded y quieres una forma estructurada de cerrar estas brechas antes de que lleguen usuarios reales, nuestra checklist sobre qué hacer después de vibe-codear tu MVP recorre los pasos de pruebas, seguridad y escalado en orden. También vale la pena revisar tu configuración de hosting contra errores comunes de hosting cloud que inflan la factura de infraestructura de una startup, ya que las sorpresas de facturación rara vez vienen de una sola fuente. Y si tu asistente de IA alguna vez sugirió instalar un paquete que no reconocías, lee sobre por qué las herramientas de codificación con IA a veces inventan paquetes falsos antes de ejecutar ese comando de instalación.

Preguntas Frecuentes

¿Por qué mi factura cloud subió de repente a más de 1000€ tras lanzar mi app?

Las causas más comunes son una clave API hardcodeada que fue copiada y usada de forma abusiva por otra persona, un bucle descontrolado en tu código frontend que envía miles de peticiones duplicadas, una base de datos pública que permitía a scripts externos extraer datos sin parar, o un endpoint de pago sin rate limiting que un bot encontró y saturó. Cada uno de estos casos multiplica muy rápido los costes basados en uso, a menudo de la noche a la mañana.

¿Es seguro usar Cursor, Claude Code o Windsurf para construir un producto real?

Sí, estas herramientas son seguras de usar y pueden acelerar significativamente el desarrollo. El riesgo no está en la herramienta en sí, sino en lanzar sin revisar áreas sensibles a la seguridad como el almacenamiento de secretos, las reglas de acceso a la base de datos y las dependencias de efectos que los asistentes de IA no siempre gestionan bien por defecto.

¿Qué es Row Level Security y por qué importa en las apps vibe-coded?

Row Level Security (RLS) es una función de base de datos en herramientas como Supabase y Firebase que restringe qué filas puede leer o escribir un usuario. Cuando el RLS se deja en su estado abierto por defecto, cualquiera con tu URL pública de API puede consultar directamente toda tu base de datos desde la consola del navegador, sin necesidad de iniciar sesión.

¿Cómo sé si mis claves API están expuestas en mi código frontend?

Abre tu sitio en producción, pulsa F12 para abrir las DevTools del navegador y revisa la pestaña Sources o Network en busca de cualquier clave que empiece por sk-, service_role, o una cadena completa de conexión a base de datos. Si tú puedes verla ahí, también puede hacerlo cualquiera que visite tu sitio.

¿Puede un error en useEffect causar realmente miles de costes extra de API?

Sí. Un array de dependencias faltante o incorrecto en un hook useEffect de React puede hacer que un componente se vuelva a renderizar y dispare su llamada API continuamente. Si pasa desapercibido en una página que los usuarios dejan abierta en una pestaña en segundo plano, esto puede generar miles de peticiones por sesión y un pico correspondiente en la facturación basada en uso.

¿Necesito contratar a un experto en seguridad antes de lanzar un MVP vibe-coded?

No necesariamente para un MVP temprano, pero sí necesitas a alguien con criterio de ingeniería de software que revise los riesgos a nivel de arquitectura antes de que usuarios reales y métodos de pago reales entren en contacto con el producto. Una revisión breve centrada en secretos, reglas de base de datos y patrones de uso de API detecta la mayoría de lo que causa sorpresas costosas.

¿Cómo compruebo si mis rutas admin o internas están realmente protegidas?

Abre la ruta en una ventana de navegación de incógnito o privada mientras estás completamente desconectado. Si todavía puedes ver la página u obtener datos de ella, no hay una comprobación de autenticación real en su lugar, y la ruta es accesible para cualquiera que encuentre la URL, incluidos los escáneres automatizados que rastrean rutas admin comunes.

¿Qué es el rate limiting y por qué lo necesita un MVP pequeño?

El rate limiting limita cuántas peticiones puede enviar un único usuario o dirección IP a un endpoint dentro de una ventana de tiempo determinada. Incluso un MVP pequeño lo necesita en cualquier endpoint que cueste dinero por llamada o toque datos sensibles, ya que sin él, un script o bot puede llamar a ese endpoint tantas veces como quiera, convirtiendo una sola ruta desprotegida en una factura ilimitada.