Cuando hablamos de enumeración de autores vía sitemap, nos referimos a la capacidad de un tercero (sin autenticación) de obtener, a través del sitemap XML, un listado de URLs asociadas a autores (páginas de archivo de autor) que permite inferir qué cuentas publican contenido y, en ocasiones, deducir identificadores reutilizables (por ejemplo, slugs de autor que coinciden con nombres de usuario o alias internos).

Esto no siempre es un fallo. Un sitemap está diseñado precisamente para facilitar el rastreo a motores de búsqueda. La cuestión es si el sitemap está publicando información que el negocio no desea hacer fácilmente agregable (y si esa agregación incrementa el riesgo al combinarse con otros factores, como login expuesto o ausencia de controles anti-automatización).

📌 Guía completa: Seguridad WordPress (checklist + prioridades).

✅ Acción rápida: Iniciar auditoría gratis y recibir evidencias en minutos.

1) Por qué pasa: cómo WordPress genera el sitemap de “usuarios/autores”

Desde WordPress 5.5 existe funcionalidad nativa de sitemaps XML y es extensible por proveedores (providers).
Dentro de esa arquitectura, WordPress incluye un provider de usuarios (WP_Sitemaps_Users).

Dos puntos técnicos son clave para entender por qué aparecen autores en el sitemap:

  1. El provider de usuarios genera URLs de autor
    La clase WP_Sitemaps_Users construye entradas cuya URL (loc) apunta a la URL del archivo de autor (en términos funcionales, “página pública del autor”). Esto se aprecia en la implementación y documentación de la clase, incluyendo el método de generación de lista y su filtro wp_sitemaps_users_entry.
  2. Por defecto, lista autores con publicaciones públicas
    La obtención de usuarios para el sitemap se apoya en argumentos filtrables y se orienta a autores con publicaciones públicas (p. ej., el criterio “tiene posts publicados”). Esto es relevante porque normalmente no lista todos los usuarios, sino un subconjunto (quienes han publicado).

Conclusión operativa: el sitemap “sugiere autores” porque WordPress considera las páginas de autor como URLs rastreables. En sitios editoriales, esto puede ser deseable; en sitios corporativos o con cuentas técnicas, puede no serlo.

2) Qué se expone exactamente (y por qué el matiz importa)

Aquí debemos ser estrictos: no todo lo que se lista equivale a “exposición de usernames”.

  • En términos generales, el sitemap de usuarios expone URLs de autor (por ejemplo, /author/alias/).
  • Ese alias suele estar basado en un identificador público del usuario (frecuentemente user_nicename o un slug). En algunos entornos coincide con el login, en otros no.

En el debate reciente del ticket #64281 en WordPress Trac se plantea explícitamente la preocupación de que el sitemap de usuarios pueda exponer “login usernames”.
Independientemente de la conclusión del ticket, lo importante para nosotros es el enfoque profesional:

No asumimos. Verificamos.
Determinamos si el slug del autor coincide con el login o si representa un alias público ya visible en el frontend.

3) Impacto: cuándo esto aumenta el riesgo de forma material

3.1 Escenario de bajo impacto

La enumeración vía sitemap suele ser bajo impacto cuando:

  • El sitio es editorial/multi-autor y las páginas de autor son parte del UX/SEO.
  • Los nombres de autor ya son visibles en el sitio (bylines, fichas de autor, etc.).
  • La postura de autenticación está madura (2FA, rate limiting, WAF, contraseñas robustas).

En este contexto, el sitemap simplemente “organiza” lo ya público.

3.2 Escenario de impacto moderado: reduce el coste de ataques automatizados

La enumeración empieza a ser un problema cuando se combina con:

  • login administrativo expuesto (/wp-login.php, /wp-admin/),
  • falta de 2FA,
  • ausencia de rate limiting o protección anti-bot,
  • y un patrón real de intentos (observado en logs).

OWASP explica que los ataques de fuerza bruta no solo ponen cuentas en riesgo, sino que además pueden ser difíciles de frenar con bloqueos simples por IP porque suelen usar proxies o distribución de orígenes.
Y en credential stuffing, OWASP remarca que herramientas modernas distribuyen peticiones en grandes volúmenes de IPs, debilitando estrategias ingenuas de limitación por IP.

En términos prácticos: si un atacante obtiene una lista de “autores existentes”, reduce la fase de prueba y aumenta eficacia del ataque combinado (usuario válido + intento de credenciales).

3.3 Escenario de impacto alto: cuentas técnicas/autores no deseados en un sitio corporativo

El riesgo sube cuando:

  • Hay cuentas administrativas o técnicas que han publicado (por error o por proceso).
  • El negocio no quiere páginas de autor indexables.
  • El sitio no necesita “entidad autor” como activo SEO.
  • Se observan ataques constantes al login o a endpoints sensibles.

En ese caso, mantener “users sitemap” suele aportar poco valor y añadir fricción de seguridad.

4) Cómo evaluarlo correctamente (metodología reproducible)

Recomendamos una evaluación en 6 pasos, basada en evidencia:

Paso 1 — Confirmar si existe sitemap nativo y el índice

Abrimos el índice de sitemaps (habitualmente wp-sitemap.xml) y verificamos si aparece el sitemap de usuarios (paginado). La existencia y estructura del sistema de sitemaps forma parte del core desde 5.5 y se gestiona por la clase WP_Sitemaps.

Paso 2 — Revisar el sitemap de usuarios

Abrimos wp-sitemap-users-1.xml (o equivalente) y listamos:

  • cuántos autores aparecen,
  • qué patrón de URL siguen,
  • si hay autores “inesperados” (cuentas técnicas, proveedores, etc.).

Paso 3 — Determinar si esas URLs son ya visibles por otras vías

Por ejemplo:

  • byline en posts,
  • enlaces internos a /author/...,
  • widgets,
  • o incluso sitemap generado por plugins SEO.

Si ya son públicas, el sitemap no crea “secreto”; crea “agregación”.

Paso 4 — Evaluar si el slug del autor es sensible

Aquí comprobamos si el slug:

  • coincide con el login,
  • coincide con emails o nombres internos,
  • o si es un alias público razonable.

El ticket #64281 en Trac muestra que esta preocupación existe y es debatida.
Nuestra práctica es verificar en el propio sitio si hay correspondencia o exposición adicional.

Paso 5 — Evaluar el “riesgo compuesto”

El sitemap rara vez es el único problema. Lo evaluamos junto con:

  • exposición de login,
  • ausencia de 2FA,
  • fuerza bruta observada,
  • y controles WAF/rate limit.

OWASP recomienda controles efectivos contra brute force y credential stuffing combinando medidas (no depender de una sola).

Paso 6 — Evaluar impacto SEO antes de actuar

Si el sitio es editorial y las páginas de autor posicionan, retirar autores del sitemap puede afectar rastreo/indexación. Por tanto, decidimos en función del modelo editorial (y no solo por “cerrar un hallazgo”).

5) Mitigación: cómo reducir riesgo sin romper SEO ni funcionalidades

Aquí proponemos opciones ordenadas por “impacto mínimo → impacto mayor”.

Opción A — Desactivar el provider “users” del sitemap (quirúrgico y recomendable cuando no aporta valor)

WordPress permite filtrar/gestionar providers de sitemap. En la introducción de la funcionalidad (WordPress 5.5), se documenta la extensibilidad del sistema, incluyendo la posibilidad de modificar providers vía filtros.
Esto permite deshabilitar el provider de usuarios cuando no queremos listar autores en el sitemap.

Cuándo conviene

  • Web corporativa.
  • Sitio con un único autor (o autores no relevantes).
  • Entornos donde el acceso al panel es un riesgo recurrente (bots).

Ventajas

  • No rompe el sitio.
  • Mantiene sitemaps de posts/taxonomías.
  • Reduce agregación de autores.

Riesgos

  • Si dependíamos de páginas de autor para SEO, puede bajar su rastreo.

Recomendación práctica: si no hay estrategia SEO para autoría, esta opción suele ser la más limpia.

Opción B — Filtrar qué usuarios entran en el sitemap (mantener autores “de negocio” y excluir el resto)

El provider de usuarios expone filtros específicos para:

  • la query de usuarios (wp_sitemaps_users_query_args),
  • la entrada por usuario (wp_sitemaps_users_entry),
  • y otros puntos de control.

Cuándo conviene

  • Sitios multi-autor donde solo una parte de autores debe ser indexable.
  • Entornos con cuentas técnicas que no deberían figurar como autores rastreables.

Ejemplos de criterios (a verificar en cada caso)

  • excluir roles (administradores “técnicos”),
  • incluir solo autores “editoriales”,
  • excluir autores sin ficha pública o sin byline.

Ventaja

  • Conserva el valor SEO donde existe.

Riesgo

  • Requiere disciplina: la política editorial debe ser consistente (quién publica y con qué cuenta).

Opción C — Gestionar los archivos de autor (cuando el negocio no quiere páginas /author/...)

Si decidimos que no deben existir páginas de autor, entonces:

  • retirarlas del sitemap no es suficiente: debemos evitar que se indexen/usen.
  • lo habitual es devolver 404, o redirigir a una página neutra, o desindexar (según estrategia).

Advertencia SEO: desactivar/alterar author archives puede impactar un sitio editorial. En corporativo, suele ser aceptable.

En esta opción, el sitemap es solo el “síntoma”: el activo (author archive) es lo que estamos decidiendo si existe o no.

Opción D — Medidas compensatorias cuando se decide mantener autores en sitemap

Si el negocio necesita author pages y sitemaps:

  • reforzamos la autenticación (2FA),
  • aplicamos rate limiting y anti-bot al login,
  • y reducimos la eficacia de enumeración (por ejemplo, que slugs no coincidan con logins internos).

Esto está alineado con OWASP: la mitigación efectiva contra fuerza bruta y credential stuffing requiere controles combinados y resistentes a rotación de IP.

6) Recomendación estándar por tipo de sitio (decisión rápida)

Sitio corporativo / institucional

Recomendación: Opción A o C (según si author pages existen por diseño).

  • Normalmente no hay valor SEO en author archives.
  • Reducir agregación suele ser preferible.

Blog multi-autor con estrategia editorial

Recomendación: Opción B + medidas compensatorias (Opción D).

  • Mantener author pages puede aportar E-E-A-T y navegación.
  • Filtrar autores “válidos” es la solución profesional.

Sitio mixto (corporativo con blog)

Recomendación: Opción B (solo autores editoriales) y excluir cuentas técnicas.

  • Evitar que el autor del blog sea una cuenta administrativa.

7) Checklist de cierre del hallazgo (criterios de aceptación)

Consideramos la enumeración vía sitemap gestionada cuando se cumple:

Evaluación

  • Hemos confirmado si existe sitemap de usuarios y qué URLs lista.
  • Hemos validado si el slug de autor coincide (o no) con el login y si aporta información adicional.
  • Hemos evaluado el riesgo compuesto con postura de login y ataques observados (brute force/credential stuffing).

Mitigación

  • Si no existe valor SEO, el provider “users” está deshabilitado (o author pages no existen).
  • Si existe valor SEO, el sitemap de usuarios se filtra para incluir solo autores “de negocio” usando filtros del provider.
  • Si se mantienen author pages, la autenticación está reforzada (2FA) y existen controles anti-automatización en login (rate limit / WAF).

8) Preguntas frecuentes

¿Esto es una vulnerabilidad “crítica”?

Por sí solo, normalmente no. Es un factor de riesgo que puede facilitar reconocimiento/enumeración. Se vuelve relevante cuando se combina con login expuesto, falta de 2FA y ausencia de controles contra automatización.

¿Eliminar autores del sitemap rompe el sitio?

No debería romper funcionalidades básicas, porque el sitemap es un componente de rastreo. Sin embargo, puede afectar rastreo/indexación de páginas de autor si dependíamos de ellas para SEO. El sistema de sitemaps nativo es extensible y gestionable por providers.

¿Cómo decidimos rápido si debemos actuar?

Si el sitio es corporativo y no hay estrategia editorial multi-autor, lo razonable es no listar autores (y, frecuentemente, no publicar author pages). En sitios editoriales, preferimos filtrar y mantener lo que aporta valor.