Prueba IDOR para vulnerabilidades de visualización por enlace copiado en tu app

Qué significa “visualización por enlace copiado” en apps reales

“Visualización por enlace copiado” ocurre cuando alguien puede abrir una página en tu app simplemente pegando un enlace, aun cuando no debería ver ese registro. Suele aparecer en facturas, proyectos, tickets de soporte, documentos compartidos y a veces en pantallas de administración que incluyen un botón de “Copiar enlace”.

La parte arriesgada no es la función de compartir. El riesgo es que la app cargue datos basándose solo en lo que hay en la URL (como un ID) sin comprobar si el usuario actual tiene permiso para verlo.

Un ejemplo común: un cliente copia el enlace a su factura y se lo manda a su contable. El contable lo abre estando conectado con su propia cuenta (o sin iniciar sesión) y aún así ve la factura. Peor aún, si la URL parece /invoice/1042, cambiarla a /invoice/1043 muestra la factura de otro cliente.

Muchos equipos asumen que están a salvo porque el enlace “parece aleatorio” (una cadena larga). Pero la aleatoriedad no equivale a permiso. Si el servidor no verifica el acceso cada vez, un enlace que parece aleatorio puede filtrar datos por compartir, reenvío, historial del navegador, capturas de pantalla o alguien que reutiliza un mensaje antiguo.

La gente suele informar esto como un comportamiento “raro”, por ejemplo:

• “Hice clic en un enlace y vi el nombre o correo de otra persona.”
• “Puedo abrir un enlace antiguo en una ventana privada y sigue funcionando.”
• “Mi compañero puede ver mi registro sin haber sido añadido a él.”
• “Soporte pidió un enlace y ahora cualquiera que lo tenga puede ver el ticket.”

Esta guía te lleva por una sencilla prueba IDOR con dos cuentas para detectar acceso directo inseguro sin leer código. Aprenderás qué probar, qué cuenta como fuga y cómo capturar pruebas que un desarrollador pueda arreglar rápidamente.

IDOR explicado sin jerga de seguridad

IDOR es la abreviatura de acceso directo inseguro a objetos. En términos simples, significa que puedes cambiar un ID en un enlace (o petición) y ver las cosas de otra persona. La app está devolviendo un objeto real (un proyecto, factura, mensaje o archivo) basándose principalmente en un identificador, sin comprobar correctamente si tienes permiso para verlo.

Un patrón típico: abres una página y la URL incluye un ID de elemento. Si cambias ese ID por otro y la app muestra el elemento de otra persona, eso es un fallo de autorización.

La distinción clave es simple:

• La autenticación responde: “¿Estás conectado?”
• La autorización responde: “¿Puedes acceder a este elemento en particular?”

Muchas apps hacen bien la primera y aún así fallan en la segunda. Estar conectado solo demuestra que eres un usuario. No demuestra que debas ver todos los registros.

Un modelo mental útil:

• Objeto: la cosa que intentas acceder (documento, pedido, ticket)
• Propietario: el usuario o equipo al que pertenece el objeto
• Comprobación de permiso: la app debe confirmar, cada vez, que el usuario actual tiene acceso a ese objeto

Si esa comprobación falta o es demasiado laxa, el comportamiento de “copiar enlace” se convierte en exposición accidental de datos.

Dónde se esconden los fallos IDOR con más frecuencia

Los problemas de IDOR no aparecen en las páginas de marketing. Aparecen en las partes “de trabajo real” de la app, donde los registros se cargan por ID y existen acciones como descargar o exportar.

Páginas que cargan un registro por ID

Son comunes porque la URL suele apuntar a exactamente un registro:

• Facturas, recibos, propuestas, informes, PDFs firmados
• Proyectos, tareas, tickets, notas, comentarios
• Perfiles, páginas de facturación, ajustes, pantallas de administración de equipo o espacio de trabajo
• Adjuntos, exportaciones, descargas de imágenes/archivos
• Páginas de “Compartir” que parecen públicas pero se pretenden privadas

Una comprobación rápida: si la página cambia completamente al modificar solo un número o un token en la dirección, podría estar confiando demasiado en el ID.

APIs en segundo plano que aún filtran

Muchas apps cargan datos desde una API en segundo plano. A veces la pantalla está protegida, pero el endpoint de la API no lo está.

Ejemplo: la página del ticket está bloqueada, pero un endpoint como “getTicket?id=123” sigue devolviendo detalles del ticket a cualquier usuario conectado.

Si heredaste una app generada por IA (Lovable, Bolt, v0, Cursor, Replit), ten más cuidado aquí. El control de acceso suele ser inconsistente entre rutas, especialmente para descargas, exportaciones y endpoints “laterales”.

Configura la prueba de dos cuentas de forma segura

Estás imitando lo que un usuario real podría hacer con un enlace compartido. Hazlo de forma segura: cuentas de usuario normales, datos solo de prueba, sesiones de navegador separadas.

1. Crea dos usuarios regulares: Cuenta A y Cuenta B. No les des permisos de administrador ni roles de “ver todo”.
2. Si tu app tiene espacios de trabajo, organizaciones o equipos, pon a A y B en diferentes espacios.
3. Con la Cuenta A, crea 1-2 elementos de prueba evidentes que reconozcas después (por ejemplo, un documento titulado “Prueba IDOR - A” o una factura ficticia de $1). Usa datos falsos.
4. Anota qué debería ocurrir. Por ejemplo: “Solo el propietario puede ver” vs “Cualquiera con el enlace puede ver, pero no editar.”
5. Mantén sesiones separadas para que los inicios de sesión no se mezclen:

• Cuenta A en una ventana normal del navegador
• Cuenta B en una ventana de incógnito/privada (o en un perfil de navegador distinto)

Paso a paso: la prueba de visualización por enlace copiado

La prueba es directa: la Cuenta A puede ver un elemento y luego la Cuenta B intenta abrir exactamente el mismo enlace copiado.

1. Inicia sesión como Cuenta A y abre un elemento objetivo (factura, proyecto, ticket, documento, hilo de mensajes).
2. Copia la URL completa desde la barra de direcciones. Observa cualquier cosa que parezca un identificador (número, cadena tipo UUID, slug).
3. En la sesión separada, inicia sesión como Cuenta B.
4. Pega el enlace exactamente y cárgalo.
5. Si algo se carga, prueba una pequeña variación cambiando solo el identificador y recargando.

Después de la página de vista, repite el mismo patrón en “puertas laterales” que con frecuencia filtran más que la pantalla principal. No hagas nada destructivo.

• Si hay una ruta de edición, comprueba si la Cuenta B puede cargar el formulario de edición.
• Si hay una acción de descarga/exportación (PDF, CSV, adjunto), comprueba si devuelve un archivo.
• Si la página se carga, fíjate en qué datos adicionales aparecen (nombres, correos, importes, notas internas).

Si la Cuenta B puede ver algo real, aunque sea una vista previa o metadatos, trátalo como un fallo de autorización.

Cómo interpretar los resultados (y qué cuenta como fuga)

No busques solo un fallo dramático de “veo todo”. Muchos problemas reales filtran lo suficiente para causar daño.

Qué resultados significan

Compara lo que la Cuenta B puede hacer con el enlace de la Cuenta A:

• Acceso completo: B ve el mismo contenido que A. Fuga clara.
• Datos parciales: B no puede usar la página normalmente, pero aun así ve nombres, importes, mensajes, adjuntos. Sigue siendo una fuga.
• Solo metadatos: B descubre que el registro existe (título, propietario, marcas de tiempo). Sigue siendo una fuga.
• Denegación correcta: B está bloqueada de forma consistente y no aparece ningún dato privado.

Un “404 Not Found” no siempre es seguro. Si algunos IDs devuelven 404 mientras otros devuelven un error distinto, una página distinta o tiempos de respuesta notablemente diferentes, puede que estés filtrando qué registros existen.

Atento a fugas silenciosas

Algunas apps ocultan la interfaz pero siguen cargando los datos. La página puede parecer en blanco, pero la respuesta (o un archivo descargado) contiene información privada.

Fíjate también en errores de permisos mixtos: la vista está bloqueada, pero la Cuenta B aún puede editar, borrar, descargar o exportar.

Prueba tanto en escritorio como en móvil. Las vistas móviles a veces golpean endpoints diferentes.

Captura evidencia que un desarrollador pueda usar

Un buen informe ahorra horas.

Recoge:

• La URL exacta usada (ruta completa y cualquier ID visible)
• Fecha/hora, entorno (producción vs staging) y navegador/dispositivo
• Prueba desde ambas cuentas (capturas de pantalla o una grabación corta)

Cuando captures pantallas, incluye algo que pruebe qué cuenta está iniciada (icono de perfil, correo, nombre de cuenta). De lo contrario recibirás “no reproducible”.

Escribe la regla que debería haberse aplicado, en lenguaje claro:

• “La Cuenta B solo debería ver sus propias facturas.”
• “Solo los miembros invitados del proyecto pueden ver este documento.”
• “Solo el remitente y el destinatario pueden leer este hilo.”

Luego lista exactamente lo que se expuso (nombres, correos, direcciones, importes, notas, adjuntos). Mantén los datos de prueba falsos y no dañinos.

Lista rápida: un escaneo IDOR de 5 minutos

Usa dos cuentas regulares (sin admin). Elige varios tipos de elementos que deberían ser privados entre usuarios.

• Confirma que las dos cuentas tienen el mismo rol y permisos.
• Prueba al menos tres tipos de elementos (por ejemplo: un documento, un archivo subido y una página de facturación).
• Para cada tipo, prueba más que “ver” (editar/cargar formulario, descargar/exportar).
• Haz un cambio “adivinable” (por ejemplo, /items/104 a /items/105, o intercambia un slug legible).
• Comprueba el comportamiento de denegación: tanto accesos no autorizados como IDs inválidos deben fallar de forma segura y consistente.

También intenta comprobar el enlace sin iniciar sesión en una ventana privada. Las páginas que deben ser privadas no deberían mostrar contenido solo porque alguien tenga la URL.

Errores comunes de prueba que hacen que se escape el fallo

Los equipos suelen ejecutar esto una vez, no ver nada obvio y seguir adelante. Algunos patrones esconden rutinariamente el problema.

• Probar dos cuentas en el mismo espacio de trabajo u organización (el cruce entre organizaciones es donde suele aparecer el fallo).
• Confundir enlaces de “compartir” verdaderos (accesibles intencionalmente) con enlaces privados (que deberían requerir la cuenta correcta).
• Suponer que los IDs largos son seguros. Si el servidor no comprueba permisos, cualquier ID válido basta.
• Solo comprobar lo que muestra la UI, no descargas/exportaciones ni datos en segundo plano.
• Parar tras una sola página. Pantallas similares a menudo se implementan con reglas distintas.

Un enfoque práctico: prueba la página de detalle, el endpoint de descarga/exportación y cualquier vista relacionada (actividad/comentarios) para el mismo objeto.

Un ejemplo simple para comparar con tu app

Imagina un portal de clientes donde cada cliente puede ver facturas. En la Cuenta A, abres una factura y haces clic en “Copiar enlace”.

Cambia a la Cuenta B (otro cliente) y pega esa misma URL de factura.

Si la Cuenta B puede ver totales, líneas, nombre del cliente o descargar el PDF, eso es una vulnerabilidad de visualización por enlace copiado. La app está confiando en el enlace (o en el ID contenido en él) más que en los permisos del usuario conectado.

Qué debería pasar en su lugar: la app bloquea el acceso a menos que la Cuenta B tenga permiso para ver esa factura. Eso podría ser una pantalla de acceso denegado, una redirección o un pedido de inicio de sesión. Si tu producto admite compartir, el enlace solo debería funcionar cuando se haya compartido explícitamente y el compartir debería poder revocarse.

Al reportarlo internamente, sé específico:

• Impacto: “Cualquier usuario conectado puede ver las facturas de otros clientes pegando un enlace copiado.”
• Áreas afectadas: “Página de detalle de factura y descarga de PDF.”
• Repro: “Iniciar sesión como A, copiar enlace, iniciar sesión como B, pegar enlace, observar que los datos/PDF se cargan.”
• Ejemplo de datos vistos: “Total de factura $X, nombre facturado, contenido del PDF.”

Cómo arreglarlo y qué hacer después

La solución que realmente funciona

Si tu verificación de dos cuentas muestra visualización por enlace copiado, la solución casi nunca está en la UI. La solución está en el servidor: cada vez que la app lee o cambia un registro, debe confirmar que el usuario logueado tiene permiso para acceder a ese registro específico.

No confíes en botones ocultos, comprobaciones del lado cliente o IDs “no adivinables”. Si un usuario puede pegar un enlace, cambiar un ID y ver datos de otra persona, la comprobación de permisos falta o es incompleta.

Qué hacer cumplir en cada endpoint vulnerable:

• Requerir autenticación cuando la página no debe ser pública
• Comprobar autorización para ese objeto exacto (propietario, miembro del espacio de trabajo, rol)
• Denegar por defecto
• Aplicar la misma regla a lecturas, escrituras, exportaciones y descargas
• Registrar intentos denegados para detectar abuso

Qué hacer después

Tras desplegar cambios, vuelve a ejecutar la misma prueba de dos cuentas contra las mismas páginas y descargas que usaste antes. Arreglar una ruta a menudo deja una “puerta lateral” abierta.

Si la app fue generada rápidamente con herramientas como Lovable, Bolt, v0, Cursor o Replit, planifica tiempo extra. Estos proyectos con frecuencia tienen varias rutas que tocan los mismos datos.

Si quieres ayuda para confirmar el alcance y parchear el control de acceso de forma limpia, FixMyMess (fixmymess.ai) se especializa en diagnosticar y arreglar bases de código generadas por IA, incluidas fallas de autorización, endurecimiento de seguridad y preparación para despliegue.