La promesa del vibe coding es real. En unas horas puedes tener una app funcionando con base de datos, autenticación y hasta pagos gracias a herramientas como Claude Code, Lovable o Cursor.
Pero que algo funcione no significa que esté bien construido. Supabase parece seguro por defecto, y en parte lo es, pero hay una serie de errores muy comunes que cometemos cuando dejamos que la IA construya rápido y no revisamos antes de publicar.
Estos son los cinco fallos de seguridad más habituales en apps construidas con IA y Supabase, y cómo corregir cada uno.
Supabase tiene dos tipos de claves para conectarte a tu base de datos. Una es semipública y está pensada para usarse en el navegador. La otra, la service role key, tiene acceso total y sin restricciones a todo, puede leer, escribir y borrar cualquier dato saltándose cualquier regla de seguridad que hayas configurado.
Claude Code, cuando está intentando que algo funcione, a veces usa esta segunda clave porque es la que "no da errores". Y si eso acaba en el código de tu app o en un repositorio público de GitHub, cualquiera puede encontrarla. Los buscadores de GitHub indexan estas cosas en minutos.
La service role key solo debe vivir en el servidor, nunca en el frontend. Antes de subir código a GitHub, revisa que tu archivo .env esté en el .gitignore.
Supabase tiene un sistema llamado Row Level Security, o RLS, que básicamente son las reglas que deciden quién puede ver o tocar qué datos. Por ejemplo, "un usuario solo puede ver sus propios pedidos" o "solo los admins pueden borrar registros".
Cuando la IA está construyendo rápido y algo no funciona, una solución fácil es desactivar el RLS para que las consultas pasen sin problemas. Muchas veces eso se queda así y nunca se vuelve a activar.
Cualquier persona que llegue a tu app, o que simplemente conozca tu clave pública, puede leer todos los datos de todos los usuarios. Y lo peor es que a veces el RLS está activado pero con una configuración que dice "permitir todo". Parece que hay seguridad, pero no la hay.
Entra en el panel y comprueba que todas tus tablas tienen RLS activado y que las políticas tienen sentido. Si ves una que dice USING (true), revísala.
Además de la base de datos, Supabase tiene un sistema de almacenamiento para subir archivos como fotos de perfil, documentos o contratos. Estos archivos se guardan en lo que llaman buckets.
Por defecto, o por comodidad, muchos proyectos dejan estos buckets en modo público. Eso significa que cualquier archivo tiene una URL directa que funciona sin necesidad de estar registrado ni autenticado. Nadie lo revisa porque "no es la base de datos", pero el riesgo es igual de serio.
Revisa la configuración de tus buckets. Si un archivo no tiene que ser público, el bucket tampoco debería serlo. Puedes generar URLs temporales para compartir archivos de forma segura.
Cuando construyes con Supabase puedes crear dos cosas que, si no se configuran bien, abren accesos no deseados a tu app.
Las Edge Functions son pequeños programas que se ejecutan en la nube y que normalmente hacen tareas específicas como enviar un email, procesar un pago o calcular algo. Si no las proteges, cualquiera puede llamarlas directamente desde fuera de tu app sin estar registrado.
Las vistas con SECURITY DEFINER son consultas guardadas que se ejecutan con los permisos de quien las creó, normalmente el administrador, en lugar de con los permisos del usuario que las está usando. Esto puede hacer que alguien acceda a datos que no debería ver aunque el resto de la seguridad esté bien configurada.
Asegúrate de que tus Edge Functions verifican que el usuario está autenticado antes de hacer nada, y revisa las vistas de tu base de datos para entender con qué permisos se están ejecutando.
Supabase tiene una clave llamada anon key que está pensada para usarse en el navegador. Es pública por diseño y eso está bien. Muchos builders la ven, leen que es "pública" y piensan que no hay ningún riesgo.
El problema no es la clave en sí, es lo que hay detrás de ella. Si tu RLS no está bien configurado, esta clave pública actúa como una llave maestra. Con ella y sin restricciones, cualquiera puede hacer consultas a tu base de datos directamente.
Este punto es la consecuencia directa del error #2. Si tus políticas de acceso están bien configuradas, la anon key no supone ningún riesgo. Repasa el punto 2 y asegúrate de que tu RLS tiene sentido.
Copia este prompt y pégalo en Claude Code antes de publicar tu app. Revisará tu proyecto punto por punto y te dirá qué está bien, qué tiene riesgo y qué tienes que corregir sí o sí.
Actúa como un experto en seguridad de aplicaciones web con experiencia en Supabase.
Voy a pedirte que hagas una auditoría de seguridad de mi proyecto antes de publicarlo.
Revisa el código y los archivos de configuración disponibles, y analiza punto por punto los siguientes aspectos. Para cada uno indícame si está bien configurado y por qué, si hay un riesgo potencial y por qué, o si hay un problema claro y cómo solucionarlo paso a paso.
1. CLAVES Y VARIABLES DE ENTORNO
- ¿Aparece la service role key de Supabase en algún archivo del frontend o en el código del cliente?
- ¿Existe un archivo .env? ¿Está incluido en el .gitignore?
- ¿Hay alguna clave secreta hardcodeada en el código fuente?
2. ROW LEVEL SECURITY
- ¿Encuentras en el código consultas a Supabase que puedan estar funcionando sin RLS activo?
- ¿Hay políticas definidas en el código con USING (true) sin condición real?
- ¿Las consultas filtran siempre por el usuario autenticado?
3. STORAGE Y ARCHIVOS
- ¿Se suben archivos a Supabase Storage? ¿Con qué configuración de bucket?
- ¿Se generan URLs directas permanentes para acceder a archivos sensibles?
4. EDGE FUNCTIONS Y VISTAS
- ¿Hay Edge Functions definidas en el proyecto? ¿Verifican el JWT del usuario antes de ejecutarse?
- ¿Hay vistas con SECURITY DEFINER? ¿Tiene sentido el nivel de permisos con el que corren?
5. ANON KEY Y ACCESO PÚBLICO
- ¿La anon key se usa correctamente, solo en el cliente y nunca para operaciones privilegiadas?
- ¿Las consultas que usan la anon key están protegidas por RLS en el backend?
Al terminar, dame un resumen con los 3 problemas más urgentes a resolver si los hay, una estimación de cuánto tiempo llevaría corregir cada uno y el orden en el que deberían abordarse.
Claude Code no es culpable de estos errores. Su objetivo es que el código funcione, no que esté auditado para producción. El modelo no sabe si tu app va a tener diez usuarios o diez mil, ni si manejas datos sensibles o no.
La buena noticia es que todos estos problemas tienen solución, y la mayoría se resuelven en menos de una hora si sabes dónde mirar. La IA también puede ayudarte a corregirlos, solo tienes que pedírselo explícitamente.
Antes de publicar tu próxima app, dedica diez minutos a revisar estos cinco puntos. Tu base de datos te lo agradecerá.
Blog escrito por Adrià Solé, Flutterflow Expert y profesor del programa en Desarrollo de Apps sin código en NocodeHackers.
Descubre lo que puedes crear en 7 días, sin saber programar
Cada día, un proyecto que podrás construir sin escribir una sola línea de código, directo a tu bandeja de entrada.
Empieza Gratis
Academia de herramientas no-code y low–code
.svg){kind=icon}
