Tu app te puede costar 100.000 € con 0 usuarios: hosting sin tope, Supabase sin RLS y alertas que no frenan

Tu app tiene cero usuarios y aun así te puede llegar una factura de cien mil euros. No es una exageración: estos tres casos son reales y les pasaron a desarrolladores normales con apps pequeñas.

1. Netlify: 104.500 $ por una web estática

En febrero de 2024, un desarrollador con una web estática en el plan gratuito de Netlify recibió una factura de 104.500 $. Alguien atacó un archivo MP3 de 3,44 MB de su web y lo descargó tantas veces que consumió unos 190 TB de transferencia en pocos días. Netlify cobraba el exceso de ancho de banda a 55 $ por cada 100 GB.

El caso se hizo viral y el CEO de Netlify le perdonó la factura. Pero el problema de fondo era sencillo: no había ningún tope de gasto que cortara el servicio al llegar a cierta cifra.

Qué hacer:

• Mira cómo cobra tu hosting el ancho de banda y busca la opción de tope o de pausa automática (en Vercel, por ejemplo, se llama Spend Management).
• Pon los archivos pesados (audio, vídeo, descargas) en un almacenamiento con el egreso controlado o detrás de un CDN con protección contra abusos.
• Añade límites de peticiones (rate limiting) en las rutas y descargas que puedan abusarse.

2. Supabase sin RLS: tus tablas, al aire

Supabase te da dos claves. La anon está pensada para usarse en el navegador: es pública y cualquiera puede verla en el código de tu web. Lo que decide qué puede hacer alguien con ella son las políticas de Row Level Security (RLS) de cada tabla.

Si no activas RLS, cualquiera con la clave pública puede leer (y a veces modificar) tus tablas: emails, pedidos, mensajes… La documentación de Supabase insiste en que RLS tiene que estar activado en todas las tablas de los esquemas expuestos.

No es teórico. En 2025, el investigador Matt Palmer revisó 1.645 apps hechas con Lovable y encontró 170 con datos expuestos por políticas de RLS ausentes o mal hechas. El fallo se registró como CVE-2025-48757.

Qué hacer:

• Activa RLS en todas las tablas y escribe políticas: cada usuario lee y modifica solo sus filas (auth.uid() = user_id).
• Pruébalo: con la clave anon y sin sesión, intenta leer cada tabla. No debería devolver nada que no sea público.
• La clave service_role se salta RLS: nunca en el navegador ni en variables NEXT_PUBLIC_ o VITE_.
• Supabase tiene un asesor de seguridad en el panel que avisa de las tablas sin RLS.

3. Una alerta de presupuesto no es un tope

En 2020, la startup Milkie Way configuró un presupuesto de 7 $ en Google Cloud para hacer pruebas. Un bucle en su código disparó millones de peticiones a Firebase y Cloud Run durante la noche y amanecieron con una factura de unos 72.000 $.

La alerta de presupuesto había saltado, pero no sirvió de nada. La documentación de Google Cloud lo dice claro: un presupuesto envía avisos, pero no limita el uso ni el gasto.

Qué hacer:

• Pon cuotas por API en los servicios que uses (número máximo de peticiones al día).
• Si quieres un corte real, Google documenta cómo desactivar la facturación automáticamente cuando el gasto supera el presupuesto. Ojo: apaga los servicios del proyecto.
• Restringe tus claves de API por dominio, IP o servicio, y no dejes funciones que se llamen a sí mismas sin límite.

El prompt para blindar las tres cosas

Pégalo en Claude Code dentro de tu proyecto (o en Claude con tu código adjunto):

Revisa esta app y su infraestructura con un objetivo: que nunca me llegue una factura sorpresa ni se filtren datos. Revisa el código y la configuración y ARREGLA lo que puedas, explicándome cada cambio:

1. HOSTING Y TRÁFICO: identifica dónde está desplegada la app y cómo cobra el ancho de banda. Dime cómo poner un tope de gasto real o la pausa automática en ese proveedor. Mueve los archivos pesados a un almacenamiento con el egreso controlado, añade rate limiting a las rutas de API y a las descargas, y bloquea el abuso de bots.

2. SUPABASE: activa Row Level Security en TODAS las tablas de los esquemas expuestos y escribe políticas para cada una (cada usuario lee y modifica solo sus filas). Comprueba que con la clave anon y sin sesión no se puede leer nada privado. Asegúrate de que la clave service_role solo se usa en el servidor y nunca aparece en el cliente ni en variables NEXT_PUBLIC_ o VITE_.

3. NUBE Y APIS (Google Cloud, Firebase, AWS, OpenAI…): recuerda que una alerta de presupuesto no frena el gasto. Propón cuotas por API, límites de gasto duros donde existan y, si hace falta, una función que desactive la facturación al superar el presupuesto. Restringe las claves de API por dominio, IP o servicio y busca bucles o funciones que puedan llamarse sin límite.

Al terminar, dame una tabla con lo que has cambiado (archivo y motivo) y una lista de lo que tengo que configurar yo a mano en cada panel, paso a paso.

Checklist antes de lanzar

• Tope de gasto o pausa automática activada en el hosting.
• Archivos pesados fuera del hosting principal o con protección contra abusos.
• Rate limiting en API y descargas.
• RLS activado en todas las tablas de Supabase, con políticas probadas.
• La clave service_role solo en el servidor.
• Cuotas por API y claves restringidas en tu nube.
• Sabes qué pasa (y quién se entera) si el gasto se dispara a las tres de la mañana.

Fuentes: documentación de RLS de Supabase, CVE-2025-48757, presupuestos de Google Cloud y desactivar la facturación con notificaciones.