IDOR en API de newsletters — la UI lo oculta, la API lo regala

Respuesta rápida

Un endpoint de una red social profesional permitía consultar la lista de suscriptores de cualquier newsletter cambiando un parámetro público en la URL. La interfaz solo mostraba el botón al propietario, pero el servidor no validaba autorización: la "protección" era puramente visual. Patrón clásico de IDOR — la UI restringe, la API no.

Contexto

La plataforma tiene un sistema de newsletters: los creadores publican contenido y los usuarios pueden suscribirse. El propietario de una newsletter puede ver su lista de suscriptores desde la interfaz, pero esa información debería ser privada y accesible solo para él.

El problema está en el endpoint que sirve esa lista. No valida en servidor que quien hace la petición sea el propietario de la newsletter.

El endpoint vulnerable

GET /voyager/api/PublishingDashSeriesSubscribers
  ?decorationId=com.target.voyager.dash.deco.publishing.SeriesSubscriberMiniProfile-2
  &count=10
  &q=contentSeries
  &seriesUrn=urn%3Ax%3Afsd_contentSeries%3A<NEWSLETTER_ID>
  &start=0
HTTP/2

El parámetro clave es seriesUrn. Contiene el ID de la newsletter. Ese ID es público — aparece en la URL de cualquier newsletter visible en la plataforma.

No hay ninguna comprobación de que el usuario autenticado que hace la petición sea el propietario de esa newsletter. Cualquier sesión autenticada puede consultar la lista de suscriptores con solo cambiar el NEWSLETTER_ID.

Pasos para reproducirlo

1. Crear una newsletter propia.
2. Abrir la newsletter y pulsar Subscribers.
3. Capturar la petición GET con Burp.
4. Identificar el parámetro seriesUrn con el NEWSLETTER_ID propio.
5. Obtener el NEWSLETTER_ID de la newsletter víctima desde su URL pública.
6. Reemplazar el NEWSLETTER_ID en la petición capturada.
7. Replay de la petición → respuesta con la lista completa de suscriptores y sus datos.

Root cause

La UI solo renderiza el botón de Subscribers al propietario de la newsletter. Eso genera una falsa sensación de seguridad. Pero la restricción visual no implica restricción en la API. Cualquier cliente autenticado puede llamar directamente al endpoint ignorando por completo lo que muestra (o no muestra) la interfaz.

Interfaz web
    ↓ Solo muestra "Subscribers" al propietario (protección solo visual)

Servidor / API
    ↓ Recibe NEWSLETTER_ID arbitrario
    ↓ ¿Comprueba que el solicitante es el propietario?  →  NO
    ↓ Devuelve lista de suscriptores

Datos expuestos

La respuesta incluye el perfil de cada suscriptor: nombre completo, cargo, empresa, foto de perfil y URL del perfil. En una plataforma con cientos de millones de usuarios profesionales, una lista de suscriptores de una newsletter de nicho puede ser información competitivamente sensible.

Impacto

• Enumeración completa de los suscriptores de cualquier newsletter, incluyendo perfiles que podrían no ser públicos o que el usuario no querría asociar a una suscripción concreta.
• Inteligencia competitiva: listas de suscriptores de newsletters de competidores, inversores, o figuras relevantes del sector.
• Base para campañas de phishing o outreach no solicitado con un nivel de segmentación muy preciso.

Qué buscar en targets similares

Este patrón aparece constantemente. Cuando audites cualquier funcionalidad que tenga un "propietario" y una lista de datos asociada:

• Captura la petición legítima desde tu cuenta.
• Identifica el parámetro que referencia el recurso (aquí seriesUrn).
• Comprueba si ese identificador es predecible o público.
• Sustitúyelo por el de otro usuario y observa la respuesta.

Si el servidor devuelve datos sin validar que el solicitante tenga acceso a ese recurso concreto, es un IDOR. El hecho de que la UI no muestre el botón no cuenta como control de acceso.

Labs relacionados

Practica IDOR sobre APIs reales con identificadores públicos y comprueba cómo separar UI-gating de la autorización real: labs de IDOR.