Cinco mil apps que pierden datos

Qué es y por qué importa

El título del vídeo sale de las noticias. Según un análisis publicado por Axios (mayo de 2026), de unas 380.000 apps publicadas con herramientas de IA, unas 5.000 exponían datos sensibles. Y TechCrunch (septiembre de 2026): la empresa UpGuard encontró unas 16.000 bases de datos en Supabase con datos personales accesibles. Cuando leo noticias así, solo me interesa una pregunta: ¿la mía está entre ellas? Usando la app no lo ves, porque con tu sesión iniciada los datos te llegan como deben. Solo lo sabes si lo pruebas.

El mecanismo, en breve. Muchas apps hechas con IA hablan directamente con la base de datos, por ejemplo Supabase, desde el navegador o el móvil. Para hacerlo llevan consigo la dirección del proyecto y una clave pública, que cualquiera puede ver. Así está bien: lo que protege los datos no es la clave, son las reglas de la base de datos. En Supabase se llaman Row Level Security. Si faltan, esa clave abre las tablas a todo el mundo.

Ya hablé de esto en la guía PORTA (strikt.fit/porta), con los detalles sobre Supabase, Firebase y las dos claves. Aquí está la versión para hacer ahora: dos pruebas de un minuto, el prompt que cierra y vuelve a probar, y cómo leer el antes y el después.

Solo en tu propia app

Esta prueba la haces en tu app y en tu base de datos, con cuentas de prueba. Nunca en la app de otra persona, ni siquiera para ver si está entre esas cinco mil: leer datos sin permiso puede ser un delito, aunque la puerta esté abierta. Si crees que una app que no es tuya está expuesta, avisa a quien la gestiona.

1. Sin iniciar sesión

La primera prueba responde a una pregunta: ¿qué ve alguien que no tiene ninguna cuenta? Lleva un minuto.

1. Abre tu app en una ventana de incógnito, sin entrar. Así el navegador no tiene tu sesión y eres un visitante cualquiera.
2. Clic derecho > Inspeccionar > Red (Network), luego recarga la página.
3. Busca una petición que vaya a .supabase.co y haz clic en ella. Ahí ves la dirección del proyecto y la clave pública (publishable, o «anon» en los proyectos más antiguos). Es normal verla: está hecha para estar en la app.

Luego abre un terminal y lanza esta línea, solo con esos dos datos. Pon tu proyecto, tu clave y el nombre de una de tus tablas:

curl "https://TU-PROYECTO.supabase.co/rest/v1/NOMBRE_TABLA?select=*" -H "apikey: CLAVE_PUBLICA"

Pruébala en cada tabla con datos de personas: perfiles, mensajes, pedidos, emails. Y hazlo en tablas que tengan datos de verdad, porque una tabla vacía responde [] aunque esté abierta: compruébalo antes en el panel de Supabase. Si vuelven filas, cualquiera puede leerlas. Si una tabla llena devuelve [] o un error de permisos, esa tabla no responde a quien pasa por ahí.

2. Como usuario A, los datos de B

La segunda prueba es la que más a menudo se salta. La puerta puede estar cerrada a quien no ha iniciado sesión y abierta a cualquiera que haya entrado. Otro minuto.

1. Crea dos cuentas de prueba, A y B.
2. Con cada una guarda algunos datos: un perfil, una nota, un pedido.
3. Entra como A e intenta abrir las filas de B, por ejemplo cambiando el id en la petición o en la dirección de la página.

Si las ves, las reglas no están. O están, pero dicen «quien ha iniciado sesión lo lee todo», y para los datos personales eso no basta: el control correcto es sobre quién es el dueño de la fila.

3. El prompt para Claude Code

Cuando sabes qué está abierto, lo haces cerrar. Abre Claude Code en la carpeta del proyecto y pega esto:

Revisa cada tabla de mi base de datos de Supabase: dime si tiene la Row Level Security activada y qué reglas (policies) tiene. Donde falte, actívala y escribe las reglas: cada usuario lee, crea, modifica y borra solo sus filas; las tablas públicas por decisión propia, solo de lectura. No pongas nunca la clave secreta (secret o service_role) en el código de la app. Luego repite la prueba: sin iniciar sesión con la clave pública, y como usuario A sobre las filas de B. Muéstrame tabla por tabla el resultado de antes y de después.

Cada parte tiene un motivo. «Lee, crea, modifica y borra» porque en Supabase las reglas se escriben para cada operación: cerrar solo la lectura deja abierto el resto. «Públicas por decisión propia» porque un catálogo lo puede leer todo el mundo, pero tiene que ser una decisión tuya, no una casualidad. Y «repite la prueba» porque una regla se comprueba probándola, no leyéndola.

Claude revisa lo que puede ver. Si las tablas están en el código del proyecto, por ejemplo en los archivos de migración, las encuentra ahí. Si las creaste a mano desde el panel de Supabase, dile tú cuáles son, o haz las dos pruebas a mano y pásale el resultado. Y si Claude Code te pide permiso para lanzar un comando, lee lo que va a hacer antes de decir que sí.

Cómo leer el antes y el después

Te conviene el resultado en una forma que se lea de un vistazo. Puedes añadir al prompt «en una tabla así» y pegar esta plantilla:

Tabla | RLS antes | RLS después | Sin sesión antes | Sin sesión después | A sobre B antes | A sobre B después
perfiles | no | sí | filas | [] | filas | nada

Al final quieres ver tres cosas: la Row Level Security activada en cada tabla, ninguna fila sin iniciar sesión salvo en las tablas públicas por decisión propia, y que A no vea nada de B. Si una tabla no sale así, pregúntale a Claude por qué antes de seguir.

Dos cosas que conviene saber

Mejor cerrado que abierto

Con la Row Level Security activada y ninguna regla, por la clave pública no pasa nada. Así que mejor cerrado que abierto, y luego abres solo lo que hace falta. Si después del arreglo una pantalla deja de cargar, no desactives la seguridad: falta una regla. Pide que te añadan esa:

La pantalla [nombre] ya no carga los datos desde que activaste la Row Level Security. Encuentra qué regla falta y añade la más estricta que baste. No desactives la seguridad en ninguna tabla. Luego repite las dos pruebas, sin iniciar sesión y de A hacia B.

La clave secreta

La clave secreta (secret o service_role) se salta todas las reglas. Va solo en el servidor: nunca en la app, nunca en GitHub. Si ha acabado en la app o en un repositorio, cámbiala enseguida desde el panel de Supabase. Quitarla del código no basta: se queda en el historial y en quien ya la ha visto.

¿No usas Supabase?

Haz la misma prueba con tu plataforma: sin iniciar sesión, y luego de A hacia B. Los nombres cambian, el concepto no. En Firebase, por ejemplo, las reglas se llaman reglas de seguridad: qué buscar y el prompt para revisarlas los tienes en la guía PORTA.

Errores comunes

• Hacer la prueba con la sesión iniciada. Usa una ventana de incógnito; si no, ves los datos porque eres tú.
• Probar una sola tabla. Cada tabla tiene sus reglas: pruébalas todas, primero las que tienen datos de personas.
• Fiarse de un [] que viene de una tabla vacía. Una tabla vacía responde [] aunque esté abierta: prueba con una que tenga datos.
• Quedarse en la prueba sin iniciar sesión. Haz también la de A hacia B: ahí se esconde la regla «quien ha iniciado sesión lo lee todo».
• Desactivar la Row Level Security cuando una pantalla no carga. Añade la regla que falta y deja cerrado el resto.
• Fiarse del arreglo sin volver a probar. Repite las dos pruebas y mira el antes y el después, tabla por tabla.

Lista de comprobación

• Prueba sin iniciar sesión, en incógnito, en cada tabla con datos de personas.
• Prueba de A hacia B con dos cuentas de prueba.
• Row Level Security activada en cada tabla, con reglas para leer, crear, modificar y borrar.
• Tablas públicas solo de lectura, y solo por decisión propia.
• Clave secreta solo en el servidor, nunca en la app.
• Las dos pruebas repetidas después del arreglo, con el antes y el después delante.

Preguntas frecuentes