En corto
- Que la pantalla solo te enseñe tus datos no significa que el servidor solo te deje pedir los tuyos. Lo primero es maquillaje. Lo segundo es seguridad.
- El navegador recibe exactamente lo que el servidor le contestó, y con F12 lo puedes leer tú. No hay que instalar nada.
- Si cambias el identificador de la URL y aparece el pedido de otro cliente, el fallo está confirmado. No hace falta más prueba.
- HTTPS cifra el viaje y la contraseña dice quién eres. Ninguno de los dos decide qué puedes pedir: eso es otra capa y hay que programarla.
- Con Supabase o Firebase el navegador habla directo con la base de datos. Si las reglas de acceso están apagadas, la clave pública abre la puerta entera.
- Este fallo no da error ni rompe nada. Solo se detecta mirando, y solo se mide su alcance si guardas registros.
Antes de seguir
No soy abogado ni delegado de protección de datos. Si al hacer estas comprobaciones descubres que hay datos personales expuestos, eso tiene consecuencias que no nos corresponde interpretar: consulta con tu asesor y con las guías de la Agencia Española de Protección de Datos.
¿Qué significa que una base de datos esté abierta?
Tu web son dos cosas separadas. La pantalla, que es lo que se dibuja en el ordenador de quien te visita. Y el servidor, que es donde están de verdad los datos. La pantalla no tiene los datos: los pide.
Cada vez que alguien abre su pedido, el navegador le hace una pregunta al servidor y el servidor contesta. La pregunta importante no es qué se ve. Es qué contesta el servidor cuando le preguntan.
Una base de datos abierta es un servidor que responde sin comprobar dos cosas: quién pregunta y si eso que pide es suyo. Da igual que la pantalla enseñe luego solo tres pedidos. Si en la respuesta venían cuatro mil, los cuatro mil ya están en el ordenador de esa persona.
Que la pantalla solo enseñe tus datos es una decisión de diseño. Que el servidor solo te deje pedir tus datos es una decisión de seguridad. Solo la segunda protege a alguien.
Tengo candado HTTPS y mis clientes entran con contraseña, ¿no basta?
No, y no porque estén mal puestos. Es que resuelven otro problema.
El candado significa que la conversación entre navegador y servidor viaja cifrada: nadie que esté en medio puede leerla. Imprescindible. Pero no dice nada sobre quién puede pedir qué. Una respuesta con la tabla entera de clientes viaja igual de cifrada que una respuesta correcta.
La contraseña resuelve la autenticación: demostrar que eres quien dices ser. Lo que falta en muchos proyectos es la autorización: decidir, petición por petición, si esa persona tiene derecho a ese dato. Son dos capas distintas y se programan por separado. Un proyecto puede tener un acceso impecable y, una vez dentro, dejar que cualquier registrado pida lo que le apetezca.
Hay una variante aún más habitual: esconder el botón. El enlace de administración solo se le enseña al administrador, pero la dirección a la que lleva responde a quien la escriba. Esconder no es proteger. Es tapar.
Cómo ver con F12 qué le pide tu web al servidor
Esto lo puedes hacer tú hoy. No se instala nada y no se rompe nada: solo miras lo que tu navegador ya recibe.
Entra en tu web con una cuenta normal de cliente, no con la de administrador. Pulsa F12, o botón derecho y luego Inspeccionar. Busca la pestaña Red, o Network si lo tienes en inglés, y recarga la página con el panel abierto. Cada línea que aparece es una pregunta que tu web le ha hecho al servidor.
Filtra por Fetch o XHR para quedarte con las que traen datos. Haz clic en una y abre la pestaña Respuesta: eso es literalmente lo que ha contestado el servidor. Ahora compáralo con lo que se ve en la pantalla.
- Si la pantalla enseña diez pedidos y la respuesta trae cientos, el filtrado se hace en el navegador. Mal sitio.
- Busca campos que no deberían salir de casa: correos de otros clientes, teléfonos, precios de coste, notas internas, tokens.
- Copia la dirección de una de esas peticiones y ábrela en una ventana de incógnito, sin haber entrado con ninguna cuenta. Si contesta con datos, el servidor no está comprobando nada.
- Mira si aparece alguna clave dentro del código o de las peticiones. Lo que llega al navegador lo puede leer cualquiera.
Cambiar el identificador de la URL: la comprobación de un minuto
Es la prueba más directa que existe.
Mira la barra de direcciones mientras tienes delante algo tuyo: un pedido, una factura, una reserva. Si la dirección termina en un número, cámbialo. Si estás en el 1043, prueba el 1042.
Lo que debe pasar: un error, un acceso no autorizado, o un mensaje diciendo que eso no existe.
Lo que no debe pasar: que aparezca el pedido de otra persona. Si aparece, no hace falta seguir investigando. El fallo está confirmado, y lo más probable es que el mismo patrón se repita por toda la aplicación.
Repite la prueba con las direcciones que has visto en la pestaña Red, que es donde vive el problema de verdad. Y con los archivos: si tus facturas en PDF se descargan de una dirección predecible, prueba a pedir otra.
Hazlo solo en tu propia web, mejor con dos cuentas de prueba creadas por ti. Y limítate a mirar.
Qué revisar si el proyecto usa Supabase, Firebase o parecidos
En estos montajes el navegador habla directamente con la base de datos. Funcionan así a propósito, y por eso llevan una clave pública dentro del código que se descarga el visitante. Cualquiera puede leerla, y se supone que da igual.
Da igual con una condición: que las reglas de acceso estén puestas. Esa clave pública no es la seguridad. La seguridad son las reglas que dicen, tabla por tabla, quién puede leer y quién puede escribir qué. En Supabase son las políticas, con RLS activado en cada tabla. En Firebase, las reglas de seguridad.
Lo que hay que mirar en el panel es corto. Que RLS esté activado en todas las tablas con datos, no en unas cuantas. Que cada tabla tenga su política de verdad, y no una permisiva puesta para trabajar cómodo durante el desarrollo. Y que las reglas no permitan leer y escribir siempre.
Una tabla con datos personales y sin reglas de acceso equivale a publicarla. Mira además qué claves viajan al navegador: la pública es normal, pero una clave de servicio o de administrador ahí se salta las reglas por diseño.
Por qué nadie te va a avisar de que se están llevando tus datos
Este fallo no da la cara. No sale un error, no se cae nada, ningún cliente se queja. De hecho funciona demasiado bien: le contesta a todo el que pregunta.
Descargarse una tabla entera no deja huella en la pantalla. Donde sí la deja es en los registros del servidor o del hosting: muchísimas peticiones a la misma dirección, con identificadores que suben de uno en uno, en pocos segundos y desde el mismo origen.
Por eso conviene guardar registros. Sin ellos no puedes responder a la única pregunta que te van a hacer luego: cuánto tiempo estuvo abierto y qué se llevaron.
Qué hago si compruebo que sí se ven los datos de otros clientes
Lo primero, no lo cuentes en abierto mientras siga abierto, y no repitas la prueba en webs que no sean tuyas. Después, orden: cerrar antes que entender, y entender antes que reescribir.
- Apunta qué has hecho y qué has visto, con fecha y hora, y guarda capturas.
- Cierra el acceso: activar las reglas en la base de datos, o añadir la comprobación de propiedad en la ruta. Si vas a tardar, deja la ruta fuera de servicio.
- Cambia las claves que hayan podido quedar expuestas. Cambiarlas es barato. No cambiarlas, no.
- Mira los registros para estimar el alcance: desde cuándo, cuántas peticiones y a qué datos.
- Pasa la misma prueba por el resto de la aplicación, y habla con quien te lleve la protección de datos si hay datos personales de por medio.
Preguntas frecuentes
¿Puedo comprobar yo mismo si mi web deja ver los datos de otros clientes?+
Sí, y sin saber programar. Entra con una cuenta normal de cliente, pulsa F12 y ve a la pestaña Red. Recarga y mira las respuestas del servidor: si traen más registros o más campos de los que se enseñan en pantalla, el filtrado se hace en el navegador. Después coge la dirección de algo tuyo, cambia el número final por otro y mira qué pasa. Debe salir un error o un acceso denegado. Si sale el dato de otra persona, el fallo está confirmado.
¿Es lo mismo estar autenticado que estar autorizado?+
No, y confundirlos es el origen de este fallo. La autenticación es demostrar quién eres: el acceso, la contraseña, el código del móvil. La autorización es decidir qué puedes pedir una vez has entrado. Una aplicación puede tener un sistema de acceso perfecto y, a la vez, contestar a cualquier usuario registrado que pida los datos de otro, porque nadie escribió la comprobación de que ese registro le pertenece. Autenticación sin autorización es una puerta con llave que da a un pasillo sin puertas.
Mi web la hizo una herramienta de IA, ¿tengo que revisar esto igualmente?+
Sí, igual que con cualquier otro origen. Estas herramientas escriben lo que se les pide, y nadie les cuenta las reglas de tu negocio sobre quién puede ver qué, porque esas reglas casi nunca están escritas en ningún sitio. Además, las configuraciones cómodas para desarrollar son permisivas por defecto y no se apagan solas al salir a producción. No es un defecto de la herramienta: es un paso que hay que dar y se queda sin dar.
¿Un escáner de seguridad automático detecta este fallo?+
Detecta una parte, pero esta no. Los escáneres buscan patrones conocidos: versiones antiguas, cabeceras mal puestas, configuraciones típicas. Este fallo no es un patrón, es la lógica de tu negocio. Ninguna herramienta genérica sabe que el usuario siete no debería ver el pedido mil cuarenta y tres. Por eso se encuentra a mano, con dos cuentas de prueba y la pregunta más aburrida del mundo: si pido lo que no es mío, ¿me lo dan?
Si descubro que los datos han estado accesibles, ¿tengo que avisar a mis clientes?+
Puede que sí, y no es una decisión para tomar con prisa. Cuando hay datos personales implicados, la normativa europea de protección de datos establece obligaciones para el responsable del tratamiento según el riesgo para las personas afectadas, y la Agencia Española de Protección de Datos publica guías sobre cómo valorarlo. Lo sensato es cerrar el acceso, documentar qué pasó y con qué alcance, y consultarlo con quien te lleve la protección de datos antes de comunicar nada.
¿Has mirado y no te ha gustado lo que has visto?
Si con estas comprobaciones ha salido algo raro, o prefieres que lo mire alguien con criterio antes de que lo mire otro, escríbenos y lo revisamos. Miramos primero lo que expone datos o dinero, te decimos qué está abierto y en qué orden se cierra, y el informe es tuyo contrates la corrección o no. Bahiages Solutions, estudio de desarrollo en Chiclana de la Frontera, trabajando para toda España.
Cuéntanos qué has encontrado