¿Cómo reviso la seguridad de mi web WordPress y compruebo qué deja al descubierto?

Por qué importa

La mayoría de los consejos de seguridad hablan de interruptores: activa esto, desactiva aquello. Pero un interruptor te dice lo que pediste, no lo que pasó. Una capa de caché puede servir una respuesta antigua. Una regla del CDN puede bloquear un archivo antes de que WordPress vea la petición. Un plugin puede volver a abrir algo que otro había cerrado. La única respuesta honesta a "¿qué deja al descubierto mi web?" es preguntárselo como lo haría un desconocido.

La buena noticia: en la parte del acceso, la lista de cosas que merece la pena revisar es corta. Los bots buscan el mismo puñado de direcciones en todas las webs WordPress:

Ninguna es un desastre por sí sola. Juntas, le dan a un bot una lista de nombres y dos puertas en las que probarlos. Saber cuáles están abiertas te permite cerrarlas en el orden correcto: primero las puertas, después los nombres.

Errores habituales

• Probar con la sesión iniciada. WordPress muestra más cosas a los usuarios conectados. Usa una ventana privada o curl.
• Probar la página en caché. Si acabas de cambiar un ajuste, vacía antes la caché de página y la del CDN, o verás la respuesta antigua.
• Quedarse en la primera luz verde. Cerrar el formulario de acceso dejando XML-RPC abierto es la solución a medias más habitual que vemos.
• Esperar una auditoría de seguridad completa. Estas pruebas tratan de las vías de entrada. No dicen nada sobre malware, cambios en archivos o plugins desactualizados.

Sin plugin

Los cinco comandos curl del paso 1 son el método manual, y merece la pena conocerlos. Lee los resultados así:

• HTTP/2 200 en wp-login.php: el acceso predeterminado es público. 404: está oculto.
• XML-RPC server accepts POST requests only. en xmlrpc.php: el endpoint está activo. Para saber si acepta accesos, tendrías que enviar una llamada wp.getUsersBlogs con una cuenta de prueba.
• Un array JSON en /wp/v2/users con campos "slug": los nombres de usuario son públicos. 401 o un array vacío: cerrado.
• Location: /author/nombre/ en ?author=1: una filtración. Repite con 2, 3, etc. para ver cuántos usuarios podría recopilar un bot.
• 200 en el sitemap de usuarios: las URL de autor están listadas.

El inconveniente es el tiempo y la interpretación. Tienes que repetirlo después de cada cambio, y probar bien el acceso por XML-RPC implica escribir XML a mano.

Si algo sale mal

• El análisis dice "abierto" pero lo desactivaste. Vacía las cachés de página y del CDN y vuelve a analizar. Si sigue abierto, puede que otro plugin o una regla del servidor esté anulando el ajuste.
• El análisis no puede llegar a tu web. Algunos alojamientos impiden que una web se haga peticiones a sí misma (loopback). Pide a tu proveedor que permita las peticiones loopback, o usa el método curl desde fuera.
• Un nombre de usuario sigue filtrándose tras el blindaje. Revisa la caja de autor de tu tema y el sitemap de autores de tu plugin de SEO. Cambia el nombre visible del autor si el tema lo muestra.

Con Hushfort

El Análisis de superficie está en el panel de Blindaje de superficie de Hushfort Security, el plugin de seguridad gratuito para WordPress. Mide lo que tu web deja realmente al descubierto con peticiones reales, igual que el método manual, y cita por su nombre los usuarios que encuentra. Cada hallazgo corresponde a una capa de Hushfort que lo cierra:

• Acceso por XML-RPC → Cierre de la puerta trasera (Pro)
• Lista de usuarios de REST, escaneos de autores, sitemap → Escudo de nombres de usuario (Pro)
• Acceso predeterminado → Ocultar acceso (gratis)

Creamos el Análisis de superficie después de que una tienda siguiera recibiendo intentos de contraseña a través de XML-RPC aunque su página de acceso estaba oculta. El ajuste parecía correcto; solo una petición real mostró la puerta abierta.