En pocas palabras: El hardening de WordPress consiste en aplicar 20 configuraciones concretas en servidor, base de datos, archivos y autenticación. Cambiar el prefijo wp_, deshabilitar XML-RPC, proteger wp-config.php y activar 2FA son los cuatro pasos de mayor impacto, documentados en la guía oficial de seguridad de WordPress.org.
El hardening de WordPress es el proceso sistemático de reforzar múltiples capas de seguridad (servidor, base de datos, archivos del sistema y capa de autenticación) para eliminar vectores de ataque específicos. No existe un plugin que lo resuelva todo: son 20 configuraciones concretas, aplicadas en capas, que reducen la superficie de ataque de cualquier sitio WordPress desde el primer día. Establece la base sobre la que el resto de capas de seguridad (actualizaciones, monitoreo) funcionan, tal como WordPress.org documenta en su guía oficial.
En 30 segundos
- El prefijo
wp_por defecto en las tablas de base de datos es explotado por scripts automatizados: cambiarlo a algo único invalida la mayoría de los payloads de inyección SQL genéricos. - XML-RPC sigue siendo uno de los vectores de fuerza bruta más usados en 2026: permite intentos de login en lote sin los límites del formulario estándar, y en la mayoría de los sitios no lo necesitás para nada.
DISALLOW_FILE_EDIT = trueen wp-config.php elimina el editor de plugins y temas desde el panel, un vector de ejecución de código si una cuenta de admin es comprometida.- Permisos 755 en carpetas y 644 en archivos es la configuración estándar: cualquier carpeta en 777 es un agujero abierto.
- Sin backup automático en servidor externo, el hardening tiene un punto ciego crítico: si el servidor es comprometido, el backup en el mismo servidor se compromete con él.
¿Qué es hardening de WordPress y por qué es crítico en 2026?
Hardening no es un destino sino una arquitectura de defensa en capas. Cada configuración invalida vectores de ataque específicos: cambiar el prefijo de tablas invalida inyecciones SQL genéricas, deshabilitar xmlrpc.php corta fuerza bruta por ese endpoint, configurar permisos correctos impide escritura no autorizada en archivos del sistema.
Según los reportes de Wordfence y Patchstack, la mayoría de los compromisos de sitios WordPress no vienen de vulnerabilidades de día cero sino de configuraciones por defecto que nunca se ajustaron, plugins desactualizados y credenciales débiles. Tres vectores que el hardening ataca directamente.
Una instalación WordPress recién hecha ya viene con varios puntos débiles activos: xmlrpc.php habilitado, editor de archivos disponible en el panel, prefijo de tablas predecible, permisos que muchos hostings dejan más abiertos de lo necesario (a veces para facilitar instalaciones automáticas, con la mejor intención). Todo eso hay que ajustarlo a mano, y a eso apuntan estas 20 configuraciones.
Proteger el acceso: cambiar URL de wp-admin y autenticación de dos factores
El 80% de los ataques a WordPress apuntan a los puntos de entrada. Reforzar la autenticación reduce el riesgo de compromiso de forma significativa, y la mayoría de estas configuraciones llevan menos de 10 minutos.
1. Cambiar la URL de wp-admin
El plugin WPS Hide Login cambia /wp-admin a cualquier ruta personalizada, por ejemplo /gestion-2026. Los bots que escanean WordPress en masa buscan /wp-login.php y /wp-admin: si esas URLs no responden, la mayoría sigue de largo. Eso sí, no es una bala de plata (un atacante con información específica sobre tu sitio puede encontrar la URL real), pero corta el ruido automatizado de forma considerable.
2. Autenticación de dos factores (2FA)
2FA con Google Authenticator o un plugin como WP 2FA agrega una segunda capa que ninguna credencial robada puede saltear sola. Para cuentas de administrador, es obligatorio. Si alguna vez revisaste los logs de intentos de login de un sitio con tráfico mediano, sabés que el volumen de intentos de fuerza bruta es constante y automatizado. Esto se conecta con lo que analizamos en proteger tu sitio con Sucuri.
3. Limitar intentos fallidos de login
Un máximo de 3 intentos fallidos por IP durante 15-30 minutos corta los ataques de fuerza bruta antes de que lleguen a probar combinaciones útiles. Wordfence, Loginizer, y Limit Login Attempts Reloaded lo implementan con configuración mínima.
4. Deshabilitar xmlrpc.php
Ponele que recibís miles de requests por día a xmlrpc.php: eso es fuerza bruta automatizada aprovechando que XML-RPC permite intentos de login en lote sin los límites del formulario estándar. A menos que uses la app móvil de WordPress o Jetpack (que lo requieren), no lo necesitás. Lo deshabilitás desde Wordfence en un clic, o con esto en .htaccess:
<Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
5. Filtrar acceso a endpoints de la REST API
La REST API en /wp-json/wp/v2/users expone usernames de tu instalación por defecto. Limitar el acceso anónimo a ese endpoint específico es directo con un filtro en functions.php o con el plugin Disable REST API. Ojo: bloquear la API completa rompe Gutenberg y WooCommerce, así que el objetivo es filtrar endpoints sensibles, no cerrar todo.
Configurar wp-config.php: las constantes de seguridad que blindan la base de datos
wp-config.php es el corazón de seguridad de WordPress. Cada constante definida ahí establece un control a nivel de código que no se puede sobrescribir desde el panel de administración, y la mayoría son cambios de una sola línea.
6. Cambiar el prefijo de tablas de base de datos
El prefijo wp_ es conocido por todos los scripts de inyección SQL automatizados. Cambiarlo a algo como seg_2026_ invalida la mayoría de esos payloads genéricos. En instalaciones nuevas, se configura antes de instalar WordPress. En sitios existentes, requiere un proceso más cuidadoso (backup verificado primero, siempre).
7. DISALLOW_FILE_EDIT = true
Esta constante deshabilita el editor de código de plugins y temas desde el panel. Si un atacante compromete una cuenta de admin, el editor de archivos es su primer destino para inyectar código malicioso. Con define('DISALLOW_FILE_EDIT', true); ese vector desaparece. Sin discusión: esto va en todos los sitios en producción.
8. DEBUG logging en archivo separado, no en pantalla
WP_DEBUG en true imprime errores en pantalla, exponiendo rutas internas del servidor y detalles del sistema a cualquier visitante (sí, en serio). La configuración correcta para producción es define('WP_DEBUG', false);. Si necesitás logs para desarrollo, define('WP_DEBUG_LOG', true); con el archivo de log fuera del directorio público web. Relacionado: autenticación de dos factores en WordPress.
9. FORCE_SSL_ADMIN = true
Fuerza HTTPS en todas las sesiones del panel de administración, incluso si el certificado no está configurado a nivel global. Con define('FORCE_SSL_ADMIN', true); las cookies de sesión nunca viajan en texto plano. En 2026 todos los sitios deberían tener SSL completo, pero esta constante agrega protección específica sobre el área de administración.
10. Claves secretas y salts únicos
Las AUTH_KEY, SECURE_AUTH_KEY y el resto de salts en wp-config.php se usan para hashear las cookies de sesión. Si usás los valores por defecto o los mismos en múltiples sitios, las sesiones son predecibles. Generá valores únicos desde api.wordpress.org/secret-key y rotálos si sospechás un compromiso.
Permisos de servidor: la configuración que más se ignora
Si alguna vez configuraste un servidor compartido, sabés que los permisos incorrectos, especialmente carpetas en 777, son el equivalente a dejar las llaves puestas. Y muchos hostings los dejan así para simplificar las instalaciones automáticas.
11. Permisos 755/644 como regla base
755 para carpetas (el propietario puede leer/escribir/ejecutar, el resto puede leer y ejecutar) y 644 para archivos (el propietario puede leer/escribir, el resto solo leer) es la configuración estándar para WordPress. Desde SSH: find /ruta/wordpress -type d -exec chmod 755 {} \; && find /ruta/wordpress -type f -exec chmod 644 {} \;
12. Ownership correcto del directorio
El propietario de los archivos debe ser el usuario del servidor web (generalmente www-data en Ubuntu/Debian o el usuario de PHP-FPM configurado). Si los archivos son propiedad de root y el servidor web corre como otro usuario, WordPress no puede escribir archivos legítimos como las actualizaciones automáticas. Verificá con ls -la en el directorio raíz.
13. Proteger wp-config.php con .htaccess
Agregá esto al .htaccess de la raíz para bloquear acceso HTTP directo a wp-config.php:
<Files wp-config.php> Order Allow,Deny Deny from all </Files>
¿Qué pasa si alguien intenta acceder igual? Recibe un 403 directamente del servidor web, antes de que PHP procese nada.
14. Deshabilitar ejecución de PHP en la carpeta uploads
wp-content/uploads es de escritura pública. Si PHP puede ejecutarse ahí, un archivo .php malicioso subido por cualquier vector se convierte en una puerta trasera. Solución: crear un .htaccess en wp-content/uploads/ con <Files *.php> Deny from all </Files>. Simple y efectivo. En configurar 2FA paso a paso profundizamos sobre esto.
15. Backup automático en servidor externo
Un backup que vive en el mismo servidor que el sitio no sirve si el servidor es comprometido (que es exactamente cuando más lo necesitás). Configurar backups automáticos a un destino externo, ya sea S3, Google Drive o SFTP externo, con UpdraftPlus o WPVivid es parte del hardening. Si tu alojamiento es donweb.com, tienen opciones de backup incluidas en los planes que podés complementar con estas herramientas para mayor redundancia.
Defensa activa: WAF, monitoreo en tiempo real y bloqueo de bots maliciosos
El hardening pasivo es necesario pero insuficiente. Aplicás las 15 configuraciones anteriores, el sitio queda bien blindado, y en tres meses aparece un plugin con vulnerabilidad nueva. Sin defensa activa, eso pasa desapercibido.
16. Activar un WAF
Un Web Application Firewall inspecciona el tráfico antes de que llegue a PHP y bloquea patrones conocidos de ataque: inyección SQL, XSS, acceso a archivos sensibles. Según Wordfence, la versión gratuita de su plugin cubre los vectores más comunes con un WAF de aprendizaje automático que se actualiza con su feed de threat intelligence. Para sitios con más tráfico o que requieren protección en la capa de red, Cloudflare WAF (plan Pro) agrega esa cobertura antes de que los requests lleguen al servidor.
17. Bloquear bots maliciosos por User-Agent
Scrapers genéricos y algunos bots de análisis consumen recursos sin aportar tráfico útil; otros son directamente maliciosos. Wordfence mantiene una lista actualizada de User-Agents problemáticos que se aplica automáticamente. Para configuración manual desde .htaccess, el patrón es BrowserMatchNoCase "NombreBot" bad_bot combinado con reglas de bloqueo.
18. Restringir acceso a wp-login.php
Limitá el acceso a la URL de login solo desde IPs conocidas, o implementá un CAPTCHA. Si tu equipo tiene IPs fijas, desde .htaccess: Order Deny,Allow / Deny from all / Allow from TU_IP. Si las IPs son dinámicas, Turnstile de Cloudflare (gratuito) o reCAPTCHA v3 son alternativas que no bloquean usuarios legítimos pero sí frenan los bots.
19. Monitoreo de integridad de archivos
El escáner de integridad de Wordfence compara los archivos de tu instalación con los hashes oficiales del repositorio de WordPress. Cualquier modificación no autorizada en archivos core aparece en el reporte. Configurarlo en escaneo semanal automático alcanza para la mayoría de los sitios; diario si manejás datos sensibles o comercio electrónico.
20. Alertas automáticas para cambios no autorizados
Configurar alertas por email para eventos críticos: nuevo usuario administrador creado, cambio en archivos core, login exitoso desde IP desconocida. Wordfence trae esto configurado; solo hay que activarlo y verificar que los emails lleguen (que no siempre es el caso si el servidor tiene problemas de deliverability, spoiler: el 40% de la gente que lo configura nunca verifica que funcione). De nada sirve blindar el sitio si no sabés cuándo algo raro sucede.
Comparativa de las 20 configuraciones: impacto, dificultad y método
| Configuración | Impacto | Dificultad | Método |
|---|---|---|---|
| 1. Cambiar URL wp-admin | Medio | Baja | WPS Hide Login |
| 2. 2FA para administradores | Alto | Baja | WP 2FA / Google Authenticator |
| 3. Limitar intentos de login | Alto | Baja | Wordfence / Limit Login Attempts |
| 4. Deshabilitar XML-RPC | Alto | Baja | Wordfence / .htaccess |
| 5. Filtrar REST API endpoints | Medio | Media | Disable REST API / functions.php |
| 6. Cambiar prefijo de tablas | Medio | Media-Alta | Instalación nueva / plugin específico |
| 7. DISALLOW_FILE_EDIT | Alto | Baja | wp-config.php (una línea) |
| 8. DEBUG logging seguro | Medio | Baja | wp-config.php |
| 9. FORCE_SSL_ADMIN | Alto | Baja | wp-config.php (una línea) |
| 10. Claves secretas únicas | Medio | Baja | api.wordpress.org/secret-key |
| 11. Permisos 755/644 | Alto | Baja | SSH / administrador de archivos |
| 12. Ownership correcto | Medio | Media | SSH (chown) |
| 13. Proteger wp-config.php | Alto | Baja | .htaccess |
| 14. Sin PHP en uploads | Alto | Baja | .htaccess en /uploads |
| 15. Backup externo automático | Crítico | Media | UpdraftPlus / WPVivid |
| 16. WAF activo | Alto | Baja | Wordfence / Cloudflare |
| 17. Bloqueo bots por User-Agent | Medio | Media | Wordfence / .htaccess |
| 18. Restringir wp-login.php | Alto | Media | .htaccess / CAPTCHA |
| 19. Integridad de archivos | Alto | Baja | Wordfence File Scanner |
| 20. Alertas automáticas | Alto | Baja | Wordfence / email configurado |
Qué está confirmado y qué todavía se debate
Configuraciones confirmadas por la industria sin debate
- DISALLOW_FILE_EDIT = true: Recomendado por la documentación oficial de WordPress.org, Wordfence y Sucuri sin excepción.
- Permisos 755/644: Estándar documentado, auditado, sin alternativa razonable.
- Deshabilitar XML-RPC: Wordfence lo recomienda explícitamente salvo que el sitio use Jetpack o la app móvil.
- 2FA para administradores: Práctica universalmente recomendada.
- Backup externo automático: Sin discusión posible.
Lo que tiene matices o genera debate
- Cambiar URL de wp-admin: Algunos profesionales lo consideran «security through obscurity» puro, que no es una práctica de seguridad real sino solo reducción de ruido. El consenso en 2026 es que reduce el ruido automatizado, pero no reemplaza 2FA y límites de intentos. Úsalo como capa adicional, no como sustituto.
- Bloquear REST API completamente: Puede romper plugins legítimos como WooCommerce y Gutenberg. Filtrar endpoints sensibles es la aproximación correcta.
- Cambiar prefijo de tablas en sitios existentes: Buena práctica en instalaciones nuevas. En producción, sin backup verificado y proceso cuidadoso, puede dejar el sitio inaccesible (y fue un dolor de cabeza descubrir por qué, si alguna vez te pasó).
Errores comunes al aplicar hardening de WordPress
1. Aplicar configuraciones críticas sin backup previo
Cambiar el prefijo de tablas o ajustar permisos sin backup reciente y verificado es apostar al todo o nada. Si algo falla en el proceso, no hay rollback. Antes de cualquier cambio estructural: backup completo (base de datos más archivos), descargado fuera del servidor, verificado.
2. Bloquear la REST API completa en vez de filtrar endpoints
El bloqueo total de /wp-json rompe Gutenberg, WooCommerce y decenas de plugins que dependen de esos endpoints. Cualquiera que haya hecho un bloqueo total sin verificar las dependencias se topó con esta sorpresa. La solución correcta es filtrar acceso anónimo a los endpoints sensibles específicos, no bloquear toda la API. Más contexto en estrategia completa contra hackers.
3. Poner wp-config.php en 400 sin verificar el usuario de PHP
Permisos 400 o 600 en wp-config.php suenan bien en papel. Pero si el propietario del archivo y el usuario de PHP-FPM no coinciden, WordPress no puede leer sus propias credenciales. El resultado es pantalla blanca de muerte. Verificá el usuario del proceso PHP antes de ajustar los permisos del archivo.
4. Creer que Wordfence instalado reemplaza todas las configuraciones
Wordfence activo con configuración por defecto no reemplaza permisos correctos, 2FA, ni backups externos. Es una capa más. Los sitios con Wordfence activo y el resto de las configuraciones intactas siguen siendo vulnerables si se compromete una cuenta de administrador sin 2FA.
Preguntas Frecuentes
¿Cómo hacer hardening en WordPress paso a paso?
El orden recomendado es: primero backup completo verificado, luego configurar wp-config.php (DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN, claves secretas únicas), después ajustar permisos de servidor (755/644) y proteger wp-config.php con .htaccess, luego configurar autenticación (2FA, límites de login, deshabilitar XML-RPC), y finalmente activar WAF y monitoreo de integridad. Patchstack documenta un proceso similar con validación en cada etapa.
¿Cuáles son las configuraciones de seguridad más importantes en WordPress?
Las de mayor impacto con menor esfuerzo son: DISALLOW_FILE_EDIT = true en wp-config.php (evita ejecución de código desde el panel si la cuenta de admin es comprometida), 2FA para administradores (bloquea acceso aunque la contraseña sea robada), deshabilitar XML-RPC (corta fuerza bruta en lote), y permisos 755/644 correctos en el servidor. Estas cuatro configuraciones cubren los vectores de ataque más frecuentes.
¿Cómo proteger un sitio WordPress de ataques de fuerza bruta?
Tres configuraciones combinadas lo resuelven: limitar intentos de login a 3 por IP (Wordfence o Limit Login Attempts Reloaded), deshabilitar xmlrpc.php (que permite intentos en lote sin los límites del formulario estándar), y agregar 2FA para que una contraseña correcta sola no sea suficiente para acceder. Opcional: bloquear wp-login.php a IPs conocidas si el equipo de gestión tiene IPs fijas.
¿Es necesario un plugin de seguridad para aplicar hardening de WordPress?
No para todas las configuraciones. Las constantes de wp-config.php, los permisos de archivos y los bloques de .htaccess no requieren ningún plugin. Pero un plugin como Wordfence simplifica la gestión del WAF, el monitoreo de integridad y los límites de login con una interfaz unificada. Para la mayoría de los sitios, la combinación de configuraciones manuales más Wordfence gratuito es el punto de partida más sólido.
¿Con qué frecuencia hay que revisar el hardening de un WordPress?
Como mínimo una auditoría trimestral: verificar que los permisos no cambiaron (algunos procesos de actualización los tocan), que las constantes de wp-config.php están en su lugar, que el WAF está activo y actualizado, y que los backups se están ejecutando y llegando al destino externo. Si el sitio tuvo actividad inusual o un plugin fue comprometido públicamente, la revisión es inmediata. Wordfence envía reportes semanales automáticos que cubren los puntos más críticos sin que tengas que hacer nada.
Conclusión
Instalás WordPress, activás un tema, subís Wordfence, y creés que está cubierto. La realidad es que xmlrpc.php sigue activo, el editor de archivos está disponible en el panel, los permisos son los que dejó el hosting por defecto, y no hay 2FA en la cuenta de admin. Ese sitio tiene más superficie de ataque de la que aparenta.
Estas 20 configuraciones, aplicadas con cuidado y un backup previo verificado, llevan entre 2 y 4 horas en un sitio existente. Para instalaciones nuevas, menos de una hora. Subís el modelo, configurás wp-config.php línea por línea, ajustás permisos desde SSH, deshabilitás xmlrpc.php, activás 2FA para todos los admins, configurás Wordfence con las alertas activas, verificás que los backups lleguen al destino externo, y el sitio queda en un estado defensivo real, no cosmético.
Arrancá por los 7 ítems de wp-config.php: son cambios de una sola línea, no requieren plugins, y tienen impacto inmediato. De ahí seguí con permisos y .htaccess. El resto viene solo.