Si un cliente ve los datos de otro: qué hacer primero

Qué significa cuando un cliente ve los datos de otra persona

Si un cliente puede ver los datos de otra persona, trátalo como urgente. Incluso si parece un fallo de la interfaz, puede exponer información privada, romper la confianza rápidamente y generar riesgos legales o contractuales (leyes de privacidad, NDA, condiciones empresariales).

“Datos de otra persona” significa cualquier información que pertenezca a un usuario, cuenta o empresa (tenant) distinta. Puede aparecer en lugares obvios o en pequeños detalles que aún identifican personas.

Ejemplos incluyen el:\n

• Nombre, correo, dirección o detalles de perfil de otro usuario
• Facturas, estado de pago, plan de suscripción o historial de facturación
• Mensajes, tickets de soporte o notas internas
• Archivos, documentos o exportaciones (CSV/PDF)
• Vistas solo para admin como listas de usuarios, logs de auditoría o claves de API

Una distinción importante:

• Un bug de aislamiento de datos es un defecto del producto que devuelve o muestra datos al tenant equivocado.
• Una violación (breach) significa que una parte no autorizada accedió realmente a los datos (tienes evidencia, o señales fuertes, de que probablemente ocurrió).

Al principio, a menudo no sabes cuál es. Actúa como si la exposición fuera real hasta que puedas demostrar lo contrario.

Los objetivos prácticos son los mismos:

1. Detener la exposición rápidamente (contención).
2. Conocer el alcance (quién vio qué, con qué frecuencia y desde cuándo).
3. Corregir la causa raíz de forma segura.
4. Comunicar claramente mientras trabajas y luego explicar qué cambió.

Contención inmediata en los primeros 15 minutos

Trátalo como un incidente de seguridad en vivo, no como un ticket normal de bug. Tu primer trabajo es detener la exposición adicional, incluso si aún no entiendes la causa.

Empieza por reconocer el informe y abrir un registro de incidente. Anota la hora exacta en que lo recibiste, quién lo reportó, qué vio (copia su redacción) y cualquier captura que aporte. A partir de ahí, pon timestamp en cada acción y decisión.

Asigna un responsable del incidente. No tiene que escribir la corrección él mismo, pero debe coordinar decisiones, llevar notas y enviar actualizaciones para que el equipo no vaya en direcciones distintas.

Reduce el radio de impacto rápido:

• Si sospechas de una función concreta (vista de admin, búsqueda, exportaciones, actividad reciente, bandeja compartida), desactívala o bloquea el endpoint.
• Si no puedes aislarlo rápido, cambia a solo lectura o modo mantenimiento para que los clientes no puedan generar nuevas peticiones que expongan datos.

Mientras contienes el problema, congela cambios riesgosos. Pausa deploys, migraciones y jobs en background que reescriben datos. Evita “arreglos rápidos” directamente en producción hasta tener una foto más clara.

Una lista de comprobación simple de contención:

• Abrir un registro de incidente con timestamps y datos del reportero
• Nombrar un responsable del incidente (y un respaldo)
• Desactivar la función/endpoint sospechoso o el rol afectado
• Usar modo solo lectura o mantenimiento si el alcance no está claro
• Pausar deploys y migraciones hasta confirmar la contención

Confirmar y acotar sin propagar más el problema

Necesitas confirmar el informe rápido sin pedir al cliente que envíe más información sensible.

Pide el conjunto mínimo de pasos que llevaron al problema. Pregunta por acciones, no por contenido privado. Detalles útiles incluyen la hora, qué página apareció y en qué workspace/cuenta estaban.

Preguntas que suelen ayudar:

• ¿Qué página o acción exacta mostró los datos de otro?
• ¿Ocurrió una sola vez o cada vez que actualizan la página?
• ¿Cerraron sesión y volvieron a entrar, o cambiaron de cuenta/workspace recientemente?
• ¿Pasa en otro navegador o en móvil?
• Aproximadamente, ¿qué cantidad de datos estaban mal (un elemento, muchas filas, toda la vista de la cuenta)?

Reproduce con seguridad. Usa un tenant de prueba nuevo y un usuario con mínimos permisos (no admin). Si necesitas dos tenants, crea dos cuentas de prueba limpias para no tocar datos reales mientras pruebas.

Luego comprueba cómo se comporta:

• Hard refresh
• Nueva sesión (incógnito)
• Segundo dispositivo

Si el problema aparece solo tras un deploy, al cambiar de cuentas o solo para un rol específico, suele apuntar a caché, manejo de sesiones o límites de autorización.

Trátalo como exposición confirmada cuando puedas reproducirlo, o cuando los logs muestren lecturas cross-tenant (aunque no puedas reproducir aún). Trátalo como sospechoso si es un informe aislado sin evidencia, pero mantén la urgencia hasta descartarlo.

Qué documentar para poder arreglarlo y explicarlo

Tus notas serán la columna vertebral de la corrección y de la explicación posterior. Captura el informe exactamente antes de que alguien lo parafrasee.

Registra:

• Quién lo reportó y cómo contactarlo
• Cuándo lo notaron
• Qué pantalla/función estaban usando
• Su descripción exacta de lo que estaba mal

Pide evidencia con cuidado. Si comparten una captura, pídeles que difuminen nombres, emails, direcciones, datos de pago y todo lo que no sea necesario para verificar el bug. Guarda archivos en una carpeta restringida y anota quién tiene acceso.

Detalles técnicos mínimos para capturar

Quieres suficientes identificadores para reproducir la ruta sin recopilar más datos sensibles de los necesarios.

Captura:

• Timestamps (con zona horaria): informe recibido, primer repro, contención y cada cambio realizado
• ID de usuario reportante y ID de tenant/workspace (y el otro tenant ID si puedes identificarlo)
• Request IDs / correlation IDs e identificadores de sesión
• Endpoints/páginas afectadas, filtros y parámetros de consulta inusuales
• Versión de la app o commit hash y hora del último deploy

Extrae snapshots de logs temprano, porque algunos sistemas rotan. Guarda logs de auth relevantes, logs del gateway/load balancer, logs de la app y consultas a la base de datos para la ventana de tiempo. Anota de dónde vienen y cuánto tiempo los mantiene el sistema origen.

Mantén una línea de tiempo continua de las acciones de contención (feature flags, accesos deshabilitados, cachés purgados, rollback iniciado) y quién hizo cada paso.

Triage rápido: causas raíz comunes para probar primero

La mayoría de las filtraciones cross-tenant vienen de un conjunto pequeño de fallos. Empieza por lo más simple y avanza hacia lo sutil.

Un orden estricto de comprobaciones

1. Autorización y filtrado por tenant

Busca lecturas que carguen registros por id sin comprobar la pertenencia, o endpoints que olviden aplicar filtros de tenant/workspace. Fíjate en rutas tipo IDOR como /invoices/123 donde el servidor no verifica que el registro pertenezca al tenant actual.

2. Confusiones de sesión

Verifica que cookies y tokens estén correctamente acotados (dominio, path, entorno). Vigila cuentas demo compartidas, claves de firma reutilizadas entre entornos o un proxy que elimina cabeceras de auth.

3. Errores de caché

Revisa caché del CDN y del servidor y las cabeceras de caching. Un Vary faltante sobre cabeceras de auth, o cachear HTML/respuestas de API que nunca deberían compartirse, puede hacer que el usuario A reciba la respuesta destinada al usuario B. Inspecciona también el estado cliente: local storage obsoleto puede mostrar datos antiguos tras cerrar sesión.

4. Bugs en consultas a la base de datos

Revisa cambios recientes en consultas, joins y scopes por defecto. Problemas comunes incluyen joins que eliminan la restricción de tenant, registros soft-deleted que aparecen en resultados y queries “fallback” cuando un filtro está vacío.

5. Jobs en background y attachments

Confirma que exportaciones, PDFs, emails y webhooks se construyen con el contexto de tenant correcto. Los workers en cola a menudo corren sin las mismas comprobaciones scoped a la petición.

Después de cada comprobación, responde una pregunta: ¿los datos incorrectos vienen del servidor o la UI está mostrando mal? Capturar el body de la respuesta de la API y sus cabeceras suele aclararlo.

Mitigaciones a corto plazo mientras se construye la corrección

Tu objetivo es detener nuevas exposiciones rápido, incluso antes de tener la causa raíz completa.

Reducir accesos mientras investigas

Si sospechas de sesiones o tokens, forzar un login limpio suele detener la fuga.

Medidas comunes a corto plazo:

• Revocar sesiones activas y exigir reautenticación (a todos los usuarios o al menos a los tenant(s) afectados).
• Deshabilitar temporalmente cambio de cuenta, impersonación y funciones de “ver como” admin.
• Pausar exportaciones y descargas (CSV, PDF) y restringir pantallas de admin que muestran muchos registros.
• Poner páginas sensibles detrás de una puerta de mantenimiento temporal si no puedes confiar aún en el aislamiento.
• Añadir límites de tasa para reducir extracción masiva mientras investigas.

Informa a soporte sobre los cambios para que puedan explicar por qué la gente fue desconectada o por qué las exportaciones están pausadas.

Añadir salvaguardas temporales

Añade comprobaciones server-side difíciles de eludir. Valida la propiedad del tenant para cada petición, no solo en la primera carga de página.

También considera desactivar la caché para endpoints y páginas sensibles (incluyendo caché de CDN o reverse-proxy). Si no puedes desactivarla por completo, reduce el tiempo de caché y asegúrate de que la clave de caché incluya contexto de tenant y usuario.

Finalmente, falla de forma segura: si el id de tenant falta, es ambiguo o no coincide, devuelve un error en lugar de adivinar.

Cómo comunicarte con el cliente que informó

Responde rápido, incluso si no tienes respuestas todavía. El silencio parece que estás ignorando un problema serio.

Usa un mensaje calmado y directo: hemos recibido el informe, lo tratamos como urgente y estamos tomando pasos para evitar más exposición mientras investigamos. No discutas, especules ni culpes su configuración.

Pide el mínimo de detalles que te ayuden a reproducir:

• Qué página o función mostró los datos incorrectos (y qué esperaban)
• La hora en que ocurrió (con su zona horaria)
• El workspace/cuenta en la que estaban
• Si se repite tras refrescar, cerrar sesión o en una ventana privada
• Una captura con campos sensibles difuminados (solo si pueden hacerlo de forma segura)

Fija una cadencia de actualizaciones que puedas mantener. Un buen defecto es: “Le enviaremos una actualización cada 2 a 4 horas, aunque sigamos investigando.”

Un mensaje conciso que puedes reutilizar:

“Gracias por avisar. Lo estamos investigando con urgencia y ya iniciamos pasos de contención para prevenir más exposición. Por favor indícanos el nombre de la página/función, la hora aproximada y el workspace en el que estabas. Te enviaremos una actualización en 2 horas y luego cada pocas horas hasta resolverlo.”

Cuando tengas una mitigación o arreglo, haz un seguimiento en lenguaje claro:

• Qué se encontró
• Qué se cambió (o se deshabilitó temporalmente)
• Qué datos pudieron haber sido visibles y durante cuánto tiempo (si se sabe)
• Qué se hará a continuación (monitorización, comprobaciones adicionales)

Cómo comunicar internamente y a otros clientes

Elige un único responsable del mensaje (a menudo el lead del incidente). Canaliza las actualizaciones a través de esa persona para que soporte, ventas e ingeniería no cuenten historias distintas.

Usa una línea de tiempo simple en cada actualización para que la gente escanee rápido: descubierto, contenido, en reparación, verificado. Usa una sola zona horaria.

Sé explícito sobre lo que sabes frente a lo que estás confirmando. No adivines. Señala la evidencia (logs, capturas, endpoints específicos) y di qué vas a comprobar después.

Cuando describas impacto potencial, nombra los tipos de datos, no categorías vagas como “datos personales”. Ejemplos: email de cuenta, nombre, nombre de la empresa, PDF de factura, últimos 4 dígitos de tarjeta, dirección de envío, texto de ticket de soporte, archivos subidos. Solo digas “no se expusieron contraseñas” si tienes prueba.

Una plantilla simple de actualización interna:

• Estado: descubierto a [hora], contenido a [hora], arreglo en progreso, verificación en progreso
• Qué ocurrió: 1-2 oraciones
• Datos potencialmente afectados: campos y pantallas específicos
• Lo que sabemos / lo que estamos confirmando: dos líneas cortas
• Próxima actualización: una hora concreta

Antes de notificar a otros clientes, alinead un desencadenante claro (por ejemplo: acceso cross-tenant confirmado, exportación/descarga confirmada expuesta, o evidencia de que duró más que una sesión).

Escenario de ejemplo: datos de tenants mezclados tras un deploy

Un ticket de soporte llega un viernes por la tarde: un cliente dice que abrió la página de Invoices y vio el número, el importe y la dirección de facturación de otra compañía.

El equipo lo trata como un posible incidente de exposición y lo contiene antes de depurar:

• Desactivan la página de Invoices con un feature flag.
• Apagan la capa de caché para las respuestas de invoice para evitar servir datos en caché mezclados.
• Revocan sesiones activas de cuentas que usaron facturación recientemente, forzando reautenticación.

Una vez contenido, reproducen el problema con dos tenants de prueba y revisan logs de acceso al endpoint de invoices. El patrón es claro: una ruta de la API devuelve tenant IDs emparejados incorrectamente, y solo desde el último deploy.

Un diff del cambio reciente muestra la causa raíz. Un refactor movió la lógica de consulta a un helper que ya no requería tenantId, así que un endpoint dejó de aplicar el filtro de tenant.

Realizan un hotfix que:

• Añade comprobaciones explícitas de autorización por tenant en el endpoint
• Añade tests que ejecutan la misma petición entre varias cuentas para confirmar aislamiento
• Falla de forma segura si falta el contexto de tenant

Hacen seguimiento con el cliente en lenguaje claro: qué pasó, qué datos pudieron haber sido visibles, qué lo detuvo y qué evita que se repita.

Errores comunes que empeoran los incidentes de exposición de datos

Pequeñas decisiones en la primera hora pueden aumentar el impacto y complicar la limpieza.

Error 1: Hacer muchos cambios sin un registro claro

Bajo presión es tentador “probar varias cosas” hasta que el problema desaparece. Entonces se pierde la pista de qué ayudó realmente y puedes destruir evidencia necesaria posteriormente.

Anota cada cambio: qué se cambió, quién lo hizo, cuándo y por qué. Trata rollbacks, toggles de feature flag y cambios de configuración como pasos formales.

Error 2: Propagar datos sensibles durante la investigación

El equipo de soporte a veces pide capturas, grabaciones o archivos exportados. Eso puede esparcir datos privados. Pide lo mínimo: timestamps, nombre de la página y pasos realizados. Si la captura es inevitable, instruye al cliente para que difumine nombres, emails, tokens y cualquier dato innecesario.

Otros errores a evitar:

• Publicar actualizaciones públicas antes de confirmar lo básico (quién está afectado, qué datos, si el acceso fue real).
• Asumir que “es solo la UI” sin verificar que el backend aplique controles de tenant.
• Probar la corrección con una sola cuenta admin y omitir otros roles o rutas de API.
• Tratar el primer informe como el único caso en vez de revisar logs en busca de patrones similares.

Una trampa común: un parche en frontend impide que la UI muestre datos mezclados y alguien declara solucionado. Más tarde descubres que la API aún permite lecturas cross-tenant vía peticiones directas. Confirma siempre el aislamiento en el servidor, en todos los roles y tenants.

Lista rápida y pasos prácticos siguientes

Trata “puedo ver datos de otro cliente” como una emergencia. Detén la exposición primero, luego reúne los hechos suficientes para arreglarlo y explicarlo claramente.

Una lista práctica, en orden:

• Contener (ahora): Desactiva la función/endpoint que muestra datos erróneos, apaga cachés riesgosos y pausa deploys/cambios de config hasta confirmar contención.
• Acotar (próx. 30-60 min): Reproduce de forma segura (cuentas de prueba), identifica pantallas/APIs afectadas y estima la ventana temporal (desde el último deploy/migración/cambio de config).
• Preservar evidencia: Guarda request IDs, timestamps, user IDs, tenant IDs y logs relevantes. Difumina capturas antes de compartirlas internamente.
• Parchear con seguridad: Añade comprobaciones explícitas de tenant, arregla claves de caché y añade tests automatizados que fallen si se cruzan límites de tenant.
• Comunicar: Reconoce el informe, mantén una cadencia de actualizaciones que puedas cumplir y documenta qué pasó, quién fue afectado y qué cambió.

Mantén un único documento de incidente desde el minuto uno. Incluye quién lo notó, cómo lo contuviste, qué mostraron los logs y el commit o cambio de config exacto que lo solucionó.

Si tratas con un prototipo generado por IA que es difícil de confiar bajo presión (especialmente alrededor de auth, checks de tenant y caché), FixMyMess (fixmymess.ai) puede ejecutar una auditoría de código gratuita para localizar el bug de aislamiento y ayudar a reparar y endurecer la app rápidamente, con la mayoría de proyectos completados en 48-72 horas.