Proteger el acceso a WordPress empieza por saber qué cuentas existen, qué puede hacer cada una y cómo se recuperan. Una contraseña fuerte ayuda, pero una cuenta administrativa sin segundo factor o con permisos excesivos sigue siendo un punto de entrada relevante.
El objetivo es reducir accesos innecesarios, detectar intentos anómalos y mantener una vía de recuperación que no dependa de un único correo o administrador.
Inventario de cuentas y roles
Elimina usuarios que ya no participan y revisa cuentas con privilegios de administrador. Los editores no necesitan gestionar plugins y un colaborador temporal no debería conservar acceso indefinidamente. Comprueba también cuentas de hosting, FTP, base de datos y servicios conectados: el panel de WordPress no es la única superficie.
Evita compartir credenciales. Una cuenta individual permite retirar acceso a una persona sin cambiar el acceso de todo el equipo y aporta contexto en los registros.
Contraseña, segundo factor y recuperación
Usa contraseñas únicas y activa MFA cuando la instalación o el proveedor lo permitan. TOTP funciona mediante códigos temporales; una llave física puede ofrecer mejor resistencia frente a páginas de inicio falsas. Guarda los códigos de recuperación fuera del servidor y define quién puede iniciar una recuperación.
El correo de recuperación debe estar protegido con el mismo cuidado. Un atacante que controla ese buzón puede superar parte del diseño de acceso aunque la contraseña de WordPress sea robusta.
Reducir intentos automatizados
El límite de intentos, la limitación de frecuencia y los registros ayudan a controlar ataques repetidos. Un bloqueo permanente puede perjudicar a usuarios legítimos y no es ideal si muchos accesos comparten IP, así que la política debe considerar duración, alertas y recuperación.
La protección del acceso no se basa en ocultar la URL de login. Esa medida puede reducir ruido, pero no sustituye MFA, contraseñas únicas, actualizaciones ni una revisión de los registros.
Permisos y código que amplía el riesgo
Un plugin vulnerable puede permitir acciones con los permisos de la aplicación. Mantén solo extensiones necesarias, revisa temas y actualiza con pruebas. Comprueba permisos de archivos y evita que procesos web puedan modificar más contenido del que necesitan.
Por ejemplo, si una cuenta de editor comprometida puede instalar plugins, el atacante puede convertir un acceso de contenido en ejecución de código. Separar capacidades reduce ese salto, aunque no elimina las vulnerabilidades del código.
Una revisión que pueda repetirse
Programa una revisión de usuarios, roles, sesiones, plugins y registros. Después de una salida de personal, una migración o un incidente, repite el inventario y rota secretos. Las copias permiten recuperar contenido, pero no impiden que una cuenta siga comprometida.
Sesiones, aplicaciones y dispositivos
Revoca sesiones antiguas después de cambiar credenciales y revisa las claves de aplicación que ya no se utilicen. Un usuario puede parecer legítimo mientras una sesión persistente sigue abierta en un dispositivo perdido. Limitar la duración y revisar accesos reduce esa ventana.
Las integraciones externas también deben tener cuentas o claves separadas. Si una API solo necesita leer entradas, no le concedas permisos de administración. La separación permite rotar una credencial sin interrumpir todo el sitio.
Registros y señales de acceso
Observa inicios de sesión fallidos, cambios de rol, instalaciones de plugins y modificaciones de correo. Una dirección IP aislada no prueba un ataque, sobre todo con redes compartidas, pero una secuencia de cambios administrativos sin explicación merece revisión.
Combina los registros del panel con los del servidor y conserva un periodo suficiente para comparar. La protección mejora cuando el equipo sabe qué señal activa una revisión y quién puede actuar.
Recuperación sin depender de una sola cuenta
Conserva un procedimiento para recuperar el acceso cuando el administrador principal no está disponible. Los códigos de recuperación, la cuenta de emergencia y el contacto responsable deben estar protegidos y revisados. Una cuenta de emergencia permanente con permisos ilimitados crea un riesgo propio.
Prueba la recuperación en un entorno controlado y registra qué ocurre con las sesiones activas. La capacidad de entrar de nuevo debe ir acompañada de la capacidad de revocar el acceso comprometido.
Evitar permisos que no se necesitan
Revisa quién puede instalar extensiones, modificar plantillas, gestionar usuarios o editar archivos. Las capacidades de WordPress y los permisos del alojamiento deben guardar relación con las tareas reales. Un rol demasiado amplio convierte un error de credenciales en un cambio de mayor impacto.
La revisión periódica es especialmente importante en equipos con colaboradores temporales o integraciones que se añadieron para una campaña y ya no se utilizan.
La protección debe revisarse también tras cambiar de equipo, añadir una integración o migrar el sitio. Cada cambio puede crear una cuenta, una clave o un permiso que después nadie recuerda retirar.
El equipo debe saber cómo informar de una sesión sospechosa y qué cuenta puede revocarla. Un control que nadie sabe operar pierde valor cuando ocurre un incidente.
Prueba el procedimiento con una cuenta de laboratorio antes de depender de él.
Revisa igualmente las cuentas que pertenecen a servicios externos y las claves usadas por automatizaciones. Una integración olvidada puede conservar más permisos que una persona y no mostrar señales en el panel hasta que se utiliza.
La revisión debe incluir una fecha y una persona responsable para que no dependa de la memoria del equipo.