Desactivar XML-RPC y limitar la REST API sin romper tu web

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

WordPress expone dos interfaces de programación que muchos sitios no necesitan pero que los atacantes usan a diario: XML-RPC y la REST API. Aprender a desactivar XML-RPC en WordPress —y a limitar la REST API con criterio en lugar de a martillazos— reduce de forma notable los intentos de fuerza bruta y de enumeración de usuarios. Este artículo pertenece a la guía pilar sobre Seguridad y hardening de WordPress, donde encajan todas estas capas.

La clave de este tema es la palabra «sin romper»: ambas interfaces tienen usos legítimos, y desactivarlas a ciegas puede tumbar la app móvil de Jetpack, un CRM conectado o el propio editor de bloques. En PathSentinel favorecemos siempre el bisturí sobre el hacha.

Por qué desactivar XML-RPC en WordPress reduce el ruido de ataques

XML-RPC (xmlrpc.php) es un protocolo antiguo que permite publicar y gestionar el sitio de forma remota. Su problema es doble. Primero, el método system.multicall permite probar cientos de contraseñas en una sola petición, multiplicando la eficacia de un ataque de fuerza bruta. Segundo, el método pingback.ping puede convertir tu servidor en un intermediario para ataques DDoS y escaneos contra terceros.

Si tu sitio no usa la app oficial de WordPress, Jetpack ni publicación remota por clientes de escritorio, casi con seguridad puedes cerrarlo sin efectos secundarios.

Cómo desactivar XML-RPC correctamente

Hay varias vías, ordenadas de más a menos robustas:

• A nivel de servidor, la opción más limpia. En Apache, un bloque <Files xmlrpc.php> Require all denied </Files>. En Nginx, location = /xmlrpc.php { deny all; }. Así la petición ni siquiera llega a PHP.
• Con un filtro en el tema o un plugin propio: add_filter('xmlrpc_enabled', '__return_false');. Detiene la autenticación por XML-RPC, aunque el archivo sigue respondiendo con un error.
• Con un plugin de seguridad reputado, si prefieres no tocar configuración. Es lo más cómodo para perfiles no técnicos.

Verifica el resultado accediendo a tudominio.com/xmlrpc.php: si el bloqueo funciona a nivel de servidor, deberías recibir un 403; si lo haces por filtro, un mensaje indicando que XML-RPC está deshabilitado.

La REST API: limitar, no destruir

La REST API (/wp-json/) es distinta: el editor de bloques Gutenberg, muchos temas y numerosos plugins dependen de ella. Desactivarla por completo suele romper el panel. El enfoque correcto es restringir el acceso anónimo a los endpoints sensibles, no anular la API.

El punto más explotado es /wp-json/wp/v2/users, que por defecto permite enumerar los nombres de usuario del sitio —un regalo para quien prepara un ataque de fuerza bruta contra el login. Puedes exigir autenticación para consultas anónimas con un filtro sobre rest_authentication_errors, o usar un plugin que bloquee la enumeración de usuarios manteniendo el resto de la API operativa.

• Bloquea la enumeración de usuarios vía REST y también vía el parámetro ?author=1.
• Mantén abiertos los endpoints que Gutenberg y tu tema necesitan.
• Registra y monitoriza los accesos a /wp-json/ para detectar sondeos.

Verificar que no has roto nada

Tras aplicar los cambios, comprueba metódicamente: entra al editor de entradas y guarda un borrador, revisa el widget de comentarios, prueba cualquier formulario y —si usas Jetpack o una app conectada— confirma que sigue sincronizando. Un cambio de seguridad que rompe una función legítima acaba revertido por prisa, y entonces vuelves al punto de partida.

Las referencias oficiales son claras en este punto: tanto la documentación de Hardening WordPress como el Wordfence Learning Center recomiendan limitar antes que desactivar cuando la interfaz tiene usos legítimos.

Encaja este cierre con el resto del hardening

Cerrar XML-RPC frena buena parte de la fuerza bruta automatizada, pero el atacante intentará entonces el login estándar. Por eso conviene combinar esta medida con proteger wp-admin y la página de login con 2FA, límites y ocultación. Y no olvides que reducir la superficie de las interfaces no sustituye a tener los plugins al día: vulnerabilidades como la de WP File Manager (CVE-2020-25213) se explotan sin necesidad de tocar XML-RPC.

Para cuantificar el impacto real de estos ajustes, conviene apoyarse en la base de datos de vulnerabilidades del NVD (NIST) y priorizar según lo que afecte a tu stack concreto. Si prefieres que lo revisemos por ti, escríbenos desde contacto.