Supabase Row Level Security: 7 errores de las apps creadas con IA

Si su app se creó con Lovable, Bolt o un creador de IA similar, es muy probable que use Supabase para su base de datos y el inicio de sesión. Es una elección razonable. También significa que un único ajuste decide si los datos de sus clientes son privados o públicos: Row Level Security, normalmente abreviado como RLS.

En 2025, investigadores de seguridad informaron públicamente de que un gran número de apps generadas por un popular creador de IA exponían datos de usuarios porque las políticas de RLS faltaban o eran demasiado débiles. Las apps funcionaban perfectamente en las pruebas, porque el creador y el propietario siempre podían verlo todo. El problema solo aparece cuando un usuario distinto, o un atacante, solicita datos que no son suyos.

Esta guía explica RLS en términos sencillos y luego repasa los siete errores que aparecen con más frecuencia en los proyectos de Supabase generados por IA, con la solución para cada uno.

RLS explicado en lenguaje sencillo

Supabase da a su frontend acceso directo a su base de datos mediante una API generada automáticamente. La clave "anon" que se incluye en su sitio web es pública por diseño. Cualquiera puede copiarla desde el navegador. Lo que protege sus datos no es la clave, sino las reglas asociadas a cada tabla.

Row Level Security es ese libro de reglas. Cada regla (una política) indica qué filas puede leer, insertar, actualizar o eliminar un determinado tipo de usuario. Una regla típica es "un usuario con sesión iniciada puede leer las filas donde user_id es igual a su propio ID". Si RLS está desactivado en una tabla, o las políticas son demasiado permisivas, el libro de reglas no se aplica y la API responderá a cualquiera.

Error 1: RLS nunca se activó

Las tablas creadas mediante SQL o archivos de migración no están protegidas hasta que se habilita RLS en ellas. Las herramientas de IA suelen crear las tablas, construir las pantallas y seguir adelante. Todo funciona porque no hay ninguna restricción.

Para comprobarlo, ejecute esto en el editor SQL de Supabase y busque cualquier tabla del esquema public donde rowsecurity sea false:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Actívelo con una línea por tabla y luego añada políticas. Habilitar RLS sin políticas lo bloquea todo, que es el punto de partida seguro sobre el que construir:

alter table public.invoices enable row level security;

El panel de Supabase también incluye un Security Advisor que señala las tablas sin RLS. Ejecútelo antes de cada lanzamiento.

Error 2: políticas que lo permiten todo

Cuando una herramienta de IA se encuentra con un error de "permission denied", un atajo habitual es una política como using (true). Hace desaparecer el error y, al mismo tiempo, hace públicos los datos.

-- Looks harmless, exposes every row to every user:
create policy "Allow read" on public.invoices
for select using (true);

Sustitúyala por una regla vinculada al usuario con sesión iniciada:

create policy "Users can read their own invoices"
on public.invoices for select
to authenticated
using ( (select auth.uid()) = user_id );

Los datos realmente públicos, como un catálogo de productos, pueden usar una política de lectura abierta. Cualquier dato personal, financiero o privado, no.

Error 3: la clave de servicio está expuesta

Supabase tiene dos claves que importan. La clave anon está pensada para los navegadores y depende de RLS. La clave service role omite RLS por completo. Si aparece en el código de su frontend, en una variable que se incluye en el bundle del sitio web o en un repositorio público, todas las políticas que haya escrito resultan irrelevantes.

Búsquela en su JavaScript compilado y en su historial de Git. Si alguna vez estuvo expuesta, rótela de inmediato en el panel de Supabase. Las claves de servicio solo pertenecen al código del lado del servidor, como una edge function o el backend, nunca a nada que el navegador descargue.

Error 4: roles almacenados donde los usuarios pueden editarlos

Un patrón frecuente es marcar a los administradores con un campo como role: "admin" dentro de los metadatos del usuario y comprobarlo después en una política o en la interfaz. En Supabase, el usuario con sesión iniciada puede modificar el área user_metadata. Un usuario puede simplemente otorgarse a sí mismo el indicador de administrador.

Guarde los datos de autorización en lugares donde los usuarios no puedan escribir: una tabla de roles dedicada que esté a su vez protegida por RLS, o app_metadata, controlado por el servidor. Después base sus políticas en eso.

Error 5: reglas de inserción y actualización sin "with check"

Una política puede controlar qué filas existentes puede tocar (using) y qué valores puede escribir (with check). Si falta la segunda parte, un usuario puede insertar filas que pertenecen a otra persona, o actualizar su propia fila para cedérsela a otra cuenta.

create policy "Users can insert their own invoices"
on public.invoices for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Users can update their own invoices"
on public.invoices for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

Error 6: vistas y funciones que se saltan las reglas

Una vista de base de datos se ejecuta por defecto con los privilegios de su propietario, lo que puede eludir el RLS de las tablas subyacentes. En Postgres 15 y posteriores puede hacer que una vista respete los permisos de quien la invoca con security_invoker = true. Del mismo modo, una función marcada como security definer y expuesta a la API se ejecuta con derechos elevados, por lo que debe comprobar quién la llama y fijar su propio search_path.

Las vistas y funciones "auxiliares" generadas por IA para paneles son una fuente habitual de este problema. Revise cada una y pregúntese: ¿con los permisos de quién se ejecuta esto?

Error 7: buckets de almacenamiento y brechas multi-inquilino

Los archivos tienen sus propias reglas, independientes de las de las tablas. Un bucket público sirve los archivos a cualquiera que tenga el enlace, lo cual es correcto para logotipos e incorrecto para contratos. Para los archivos privados, organice las cargas por usuario o inquilino y escriba políticas de almacenamiento acordes, por ejemplo exigiendo que la primera carpeta de la ruta sea igual al ID del usuario:

create policy "Users can read their own files"
on storage.objects for select
to authenticated
using (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

En las apps con equipos u organizaciones, cada política debe acotarse al inquilino mediante una tabla de membresías, no solo al usuario individual. Ahí es también donde las políticas escritas por IA suelen volverse incoherentes de una tabla a otra.

Cómo probar su propia app en 15 minutos

1. Prueba anónima. Llame a los endpoints de sus tablas usando solo la clave anon pública y sin iniciar sesión. Las tablas privadas deben devolver vacío o un error.
2. Prueba con dos cuentas. Cree dos usuarios con datos separados. Como usuario B, intente leer, editar y eliminar los registros del usuario A cambiando los ID en las solicitudes.
3. Prueba de privilegios. Como usuario normal, pruebe directamente las funciones de administración e intente cambiar su propio rol.
4. Ejecute el Security Advisor y corrija todas las advertencias sobre RLS.
5. Conserve las pruebas. Supabase admite pruebas automatizadas de la base de datos, de modo que un cambio futuro no pueda reabrir un hueco sin que nadie se dé cuenta.

Si ya ha lanzado

Habilite RLS y corrija primero las políticas, y luego rote las claves que hayan estado expuestas. Revise sus registros en busca de accesos inusuales. Si los datos personales de usuarios reales pueden haber quedado expuestos, es posible que tenga obligaciones legales de notificarlos, según el lugar donde vivan, así que consulte a un abogado. Corregir las reglas de acceso suele ser rápido. Averiguar qué ocurrió y qué debe comunicarse lleva más tiempo, otra razón para encontrar estos problemas antes del lanzamiento.

¿No sabe en qué punto se encuentra su app? Nuestra auditoría técnica de apps con IA revisa sus políticas, claves y almacenamiento y le entrega una lista priorizada de correcciones. Si ya sabe qué está roto, el servicio de reparación y lanzamiento a producción de apps con IA cubre las correcciones y un lanzamiento controlado. También puede empezar con la lista de verificación de preparación para producción, más amplia.