Cómo comprobar en 15 minutos si tu app hecha con IA filtra datos

Por Kike Gandia · Co-Fundador y CEO, OSCP

No hace falta ser técnico ni instalar nada para descartar los fallos más graves de una aplicación generada con IA. Hacen falta dos cuentas de prueba, el navegador y un cuarto de hora. Esta guía es el procedimiento exacto, paso a paso, con la interpretación de cada resultado. Hazlo siempre sobre tu propia aplicación: ejecutar estas comprobaciones contra un sistema ajeno sin autorización es delito en España, con independencia de la intención.

Lo que necesitas antes de empezar

Tres cosas, ninguna de pago:

Dos cuentas de usuario en tu propia aplicación, con datos distintos en cada una. Llámalas A y B y anota qué has metido en cada una.
Las herramientas de desarrollo del navegador, que se abren con F12 en Chrome o Firefox. Vas a usar dos pestañas: Red y Consola.
Una ventana de incógnito, para comprobar qué ve alguien sin sesión iniciada.

Reserva quince minutos sin interrupciones y no hagas las comprobaciones en horario de alta carga si tu aplicación ya tiene usuarios reales.

Minuto 1 a 5: qué viaja al navegador

Abre tu aplicación con las herramientas de desarrollo en la pestaña Red y navega por ella con normalidad: entra, carga una pantalla con datos, guarda algo.

Mira las peticiones que aparecen. Busca dos cosas concretas:

La dirección de tu base de datos. En las aplicaciones generadas suele verse una URL del proveedor de datos, con una clave larga acompañándola. Que sea visible es normal y esperado: el problema nunca es que se vea, sino qué permite hacer.

Claves que no deberían estar ahí. Busca cadenas que empiecen por prefijos de servicios de pago, de correo transaccional o de APIs de terceros. Si una clave da acceso a cobrar, enviar correo o consumir cuota, no debería viajar nunca al navegador.

Apunta la dirección de la base de datos: la necesitas para el paso siguiente.

Minuto 5 a 10: la comprobación que más descarta

Esta es la importante. Cierra sesión por completo o abre una ventana de incógnito, y vuelve a cargar una pantalla que muestre datos.

Si sigues viendo registros sin haber iniciado sesión, la capa de datos está abierta. Cualquiera puede pedir esa información con las credenciales que acabas de ver en la pestaña Red. Es el fallo más grave de la lista y no requiere ninguna habilidad para explotarlo.

Si la aplicación te redirige al login y no devuelve nada, bien: hay al menos un control de autenticación. Pasa al siguiente paso, porque eso todavía no significa que estés protegido.

Minuto 10 a 15: el fallo que sobrevive al login

Ahora entra con la cuenta A y localiza un registro cualquiera —una nota, un pedido, un documento—. Fíjate en su identificador: suele estar en la URL o en la respuesta de la petición.

Cierra sesión, entra con la cuenta B y pide ese mismo identificador: cambiándolo en la URL si aparece ahí, o repitiendo la petición desde la pestaña Red.

Si desde B puedes ver el registro de A, tienes autorización rota. La aplicación comprueba que estás autenticado pero no de quién es cada dato. Es el segundo fallo más común y el más traicionero, porque se cuela en todas las pruebas funcionales: cada usuario probando lo suyo nunca lo detecta.

Repite la prueba intentando modificar o borrar el registro de A desde B. Es frecuente cerrar la lectura y dejar la escritura abierta.

Cómo interpretar lo que has encontrado

Lo que has visto	Qué significa	Gravedad
Datos visibles sin iniciar sesión	La base de datos no tiene control de acceso	Crítica: ciérralo hoy
La cuenta B ve datos de la A	Autenticas pero no autorizas	Crítica
La cuenta B puede editar o borrar datos de la A	Escritura sin comprobar propiedad	Crítica
Claves de pago o correo en la pestaña Red	Secreto expuesto, uso a tu costa	Alta: rótala
Un fichero subido se abre sin sesión	Almacenamiento con reglas abiertas	Alta
Nada de lo anterior	Los fallos de configuración más graves están descartados	Queda la lógica de negocio

Un resultado limpio es una buena noticia y no es un certificado. Estas comprobaciones cubren la configuración, que es donde falla la mayoría de aplicaciones generadas, pero no cubren la lógica propia de tu producto: precios manipulables, flujos de estado que se pueden saltar o permisos que escalan por un camino no previsto. Eso no se detecta mirando, hay que atacarlo.

FAQ

¿Puedo hacer estas comprobaciones en una app que ya tiene usuarios?

Sí, son de solo lectura salvo la última, en la que intentas modificar un registro. Hazla con datos de prueba tuyos, nunca sobre contenido real de un cliente, y en un momento de baja carga. Ninguna de las cinco genera volumen relevante ni altera la configuración de la aplicación.

He encontrado un fallo, ¿qué hago primero?

Cierra el acceso antes que ninguna otra cosa: activa las reglas de acceso por fila exigiendo propiedad del registro. Después rota cualquier clave que hayas visto expuesta, porque debes asumir que ha podido ser copiada. Y solo entonces evalúa el alcance: qué datos han estado accesibles y durante cuánto tiempo, que es lo que determina si hay obligación de notificar.

¿Estas pruebas valen si mi app no usa Supabase?

Sí. El procedimiento no depende del proveedor: comprueba comportamiento, no tecnología. Firebase, Appwrite, Pocketbase o un backend propio tienen el mismo modelo de fondo cuando el navegador habla directamente con los datos, y los tres resultados posibles —ves datos sin sesión, ves datos ajenos, no ves nada— significan lo mismo en todos ellos.