Los datos de tu app hecha con IA pueden estar a la vista: qué es RLS y cómo comprobarlo en 10 minutos
· Javier Miralles · 7 min
Montaste una app con Lovable, Bolt, v0 o Cursor, guarda datos de tus clientes —nombres, teléfonos, pedidos— y funciona. La usas cada día y nada falla. Pero hay una pregunta que no te has hecho, porque nadie te avisó de que había que hacérsela: ¿puede otra persona leer esos datos sin permiso?
En muchas apps hechas con IA la respuesta es que sí, y lo peor es que no se nota. No hay error, no hay aviso, no hay pantalla rota. La base de datos está abierta de par en par y la app va como si nada. Vamos a ver por qué pasa esto, cómo comprobarlo tú en diez minutos sin saber programar, y qué hacer si resulta que está abierta.
En corto
Las apps hechas con IA suelen guardar los datos en servicios como Supabase o Firebase. Estos servicios tienen una particularidad: exponen la base de datos directamente al navegador, para que la app pueda leer y escribir sin un servidor propio por medio. Eso es cómodo, pero significa que la puerta de tu base de datos da a la calle.
Quien decide si esa puerta está cerrada no es una contraseña oculta, son unas reglas de acceso que hay que configurar a mano: RLS en Supabase, Security Rules en Firebase. Si esas reglas se quedaron desactivadas desde la demo —que es lo que pasa por defecto mientras construyes— tu base de datos está abierta a cualquiera que sepa dónde mirar. La buena noticia: comprobarlo son diez minutos, y arreglarlo no obliga a rehacer la app.
Por qué mis datos podrían estar a la vista
Cuando programas una app "de toda la vida", hay un servidor en medio que hace de portero: el navegador le pide cosas y el servidor decide qué entrega. Supabase y Firebase quitan ese portero para ir más rápido. La app del navegador habla directamente con la base de datos usando una clave pública.
Y aquí está el detalle que confunde a todo el mundo: esa clave es pública a propósito. Está en el código que se descarga tu navegador, cualquiera puede verla, y eso no es un fallo. No es como la contraseña de tu correo. La clave solo dice "soy una visita de esta app"; lo que esa visita puede hacer lo deciden las reglas de acceso.
RLS —Row Level Security, seguridad a nivel de fila— es esa regla en Supabase. Fila por fila, decide quién puede ver o tocar cada dato. Bien puesta, cada cliente ve solo lo suyo. El problema es que mientras construyes la app, lo normal es tenerla desactivada para que no te estorbe: eres tú solo probando, no hace falta portero. Y si nadie la activa antes de publicar, la app sale a producción con la puerta abierta. Firebase tiene su equivalente, las Security Rules, y un modo de prueba que deja la base de datos abierta durante 30 días "para que empieces sin líos".
Sabiendo esto, ya no es un misterio: solo hay que ir a mirar en qué estado están esas reglas.
Cómo comprobarlo en diez minutos
No hace falta programar. Si tu app va sobre Supabase, entra en su panel (supabase.com, tu proyecto) y abre el Table Editor. Verás tus tablas: usuarios, pedidos, clientes, las que sean. Fíjate en cada una. Supabase marca con un aviso o con la etiqueta "Unrestricted" las tablas que tienen RLS desactivado. Esa palabra es la señal de alarma: esa tabla está abierta.
Después ve a la sección de Policies (Authentication → Policies, o el botón de políticas dentro de cada tabla). Ahí ves, tabla por tabla, si RLS está activado y qué reglas tiene. Con esta tabla decides en diez segundos qué te has encontrado:
| Estado de la tabla | Qué significa | Qué hacer |
|---|---|---|
| RLS desactivado ("Unrestricted") | Cualquiera con la clave pública puede leer y escribir todo | Activar RLS y añadir políticas. Urgente si hay datos de personas |
| RLS activado, sin ninguna política | Nadie accede por la API. La app puede dejar de funcionar | Añadir las políticas que definan quién ve qué |
| RLS activado y con políticas | Solo accede quien la política permite | Leer la política y confirmar que dice lo que crees |
Si tu app va sobre Firebase, el sitio a mirar es Firestore Database → Rules: si ves algo tipo allow read, write: if true; o una fecha de caducidad del "modo de prueba", está abierta a todo el mundo.
Y si no tienes acceso a ninguno de esos paneles porque te montó la app otra persona, esa es la primera cosa que le tienes que pedir: acceso al proyecto. Sin eso no puedes ni comprobar ni proteger nada.
Un ejemplo con números
Pongamos un caso tipo, inventado para que se entienda. Una academia pequeña monta con Bolt una app para gestionar matrículas. La tabla alumnos acaba con 300 registros: nombre, teléfono, email y qué han pagado. En la demo, con 3 alumnos de prueba, todo iba perfecto, así que la publicaron tal cual.
RLS se quedó desactivado desde el primer día. Durante meses, la app funcionó sin un solo error: los profes entraban, veían las listas, cobraban. Nada falló. Pero cualquiera que abriera las herramientas del navegador y mirara a dónde pedía datos la app podía pedirlos también, y llevarse los 300 alumnos completos. Teléfonos y emails incluidos.
Nadie lo notó porque no hay nada que notar: una base de datos abierta se ve exactamente igual que una cerrada, hasta que alguien mira. El arreglo fueron un par de horas: activar RLS en las tablas con datos y escribir dos políticas ("cada usuario ve los alumnos de su academia"). Ni una línea de la app tocada. Ese es el patrón normal, no la excepción.
Que sean datos de personas, además, cambia lo que hay en juego: si esos 300 teléfonos hubieran salido, no es solo un susto técnico, puede ser una brecha de datos personales con obligaciones legales detrás. Eso mejor consultarlo con quien te lleve la protección de datos; aquí el mensaje es más simple: revísalo antes de que sea una historia y no un ejercicio.
¿Qué hago si está abierta?
Que no cunda el pánico. Encontrarse RLS desactivado no significa que te hayan robado nada, significa que la puerta estaba abierta y aún estás a tiempo de cerrarla. El orden es este:
- Primero, las tablas con datos de personas (clientes, usuarios, cualquier cosa con nombres, contactos o pagos). Activar RLS ahí es lo urgente.
- Luego, una política por cada tabla. Una política es una frase de reglas: "un usuario solo ve sus propios pedidos", "solo los administradores escriben en esta tabla". Aquí es donde conviene ir con cuidado: una política mal escrita puede dejar la app sin funcionar (todo bloqueado) o seguir dejando demasiado abierto. Se prueba con calma.
- Al final, comprobar que la app sigue yendo. Al activar RLS, si a alguna consulta le falta su política, dejará de traer datos. Es esperable y se resuelve añadiendo la política que faltaba, no desactivando RLS otra vez (ese es justamente el error que abrió la puerta).
Si te ves escribiendo políticas a ciegas, o la app empieza a fallar en cadena cada vez que tocas una, es señal de que conviene que lo mire alguien con las manos en Postgres. No porque sea imposible aprenderlo, sino porque en datos de terceros el margen de error es pequeño y el coste de equivocarse, alto.
Cuándo hacerlo tú y cuándo pedir ayuda
Comprobar el estado —abrir el panel, mirar qué tablas están "Unrestricted", ver si hay políticas— lo puedes hacer tú hoy, y deberías, aunque solo sea para saber en qué punto estás. Es información que necesitas tener tú, no tu proveedor.
Pide ayuda cuando el panel diga cosas que no entiendes, cuando actives RLS y la app empiece a romperse por sitios que no esperabas, o cuando manejes datos de clientes y quieras que alguien confirme que están de verdad protegidos y no solo aparentemente. Es justo el terreno donde una comprobación de diez minutos evita un problema de meses.
Si estás en ese punto, lo podemos mirar sin compromiso: nos pasas el enlace de la app (o el proyecto de Supabase/Firebase) y te decimos qué está expuesto, qué falta y cuánto costaría dejarlo cerrado, con cifra cerrada. Cómo enfocamos el rescate de apps hechas con IA está en la página del servicio, y si prefieres escribir directamente: contact@easybyte.es.
Preguntas frecuentes
¿De verdad puede leer cualquiera los datos de mi app hecha con IA?
Puede pasar si tu app guarda los datos en Supabase o Firebase y las reglas de acceso están desactivadas. Estos servicios exponen la base de datos directamente al navegador, y quien la protege son las políticas de acceso (RLS en Supabase, Security Rules en Firebase), no el que la clave esté oculta. Si esas reglas se quedaron apagadas desde la demo, la base de datos está abierta aunque en el uso normal nada falle.
¿Qué es RLS?
RLS son las siglas de Row Level Security, o seguridad a nivel de fila. Es la regla que decide, fila por fila, quién puede ver o tocar cada dato de una tabla. Con RLS bien puesto, cada usuario solo ve lo suyo; con RLS desactivado, cualquiera con la clave pública de la app puede leerlo todo.
¿Cómo compruebo si mi base de datos está abierta?
En Supabase, entra en el panel, abre el Table Editor y mira cada tabla: si aparece marcada como 'Unrestricted' o con un aviso de RLS desactivado, esa tabla está abierta a cualquiera. Cada tabla con datos debería tener RLS activado y al menos una política que diga quién ve qué. En Firebase, revisa que las Security Rules no estén en 'modo de prueba'.