Guía de Seguridad WordPress 2025

Introducción

La seguridad no es un estado, sino un proceso continuo de reducción de riesgos. Piensa en ella como en la salud personal, no basta con una sola visita al médico; necesitas revisiones periódicas, buena dieta y algo de ejercicio. En WordPress, esto significa llevar a cabo tareas como actualizar a tiempo, eliminar las vulnerabilidades detectadas, mejorar de forma continua los controles de seguridad, guardar copias de seguridad en diferentes soportes y monitorización constante. En lugar de confiar en una única barrera, se superponen capas independientes, si una falla, las demás siguen protegiendo.

Panorama de amenazas 2025

Durante las últimas décadas, WordPress ha pasado de ser “solo un gestor de blogs” a convertirse en la plataforma que impulsa más del 40 % de las webs que existen. Ese éxito también la convierte en un objetivo prioritario: los atacantes buscan fallos automatizados que afecten a miles de sitios en cuestión de horas. Entender el panorama actual, quién ataca y con qué técnicas, es el primer paso para diseñar una defensa efectiva, sobre todo si administras tu web en solitario o con recursos limitados.

Métricas clave (actualizadas a 2025)

56 % de las vulnerabilidades están en plugins. El núcleo apenas representa entre el 1 y el 4% de fallos de seguridad; el foco real son extensiones y temas. (Fuente nitropack.io)

86 000 M de ataques de contraseña bloqueados / año. La fuerza bruta sigue liderando. (Fuente: Nitropack nitropack.io)

Vectores principales: fuerza bruta, XSS, CSRF, inyecciones SQL y file-inclusion. Mantener todo actualizado mitiga la gran mayoría de ataques.

Google advierte a 12–14 millones de usuarios al día sobre sitios potencialmente maliciosos y pone en lista negra >10.000 webs/día por malware o phishing. Esto subraya que el riesgo es masivo y constante. (Fuente: WPBeginner)

Aproximadamente un 43% de todas las webs que existen usan WordPress; su enorme cuota lo convierte en objetivo prioritario, por lo que cualquier brecha en plugins/temas se vuelve rápidamente atractiva para los atacantes. (Fuente: nordlayer.com)

Empecemos por el servidor

Un buen hosting es la base de toda estrategia de seguridad: si el servidor es lento, inestable o está mal configurado, el resto de medidas de seguridad se vuelven inservibles. Prioriza rendimiento, fiabilidad y seguridad por encima del precio; un proveedor barato que ahorra en protección suele salir caro a largo plazo (tras el primer incidente serás consciente de esta necesidad).

¿Qué debe ofrecer tu hosting?

  • WAF y filtrado de bots a nivel de red (antes de que el tráfico llegue a PHP). Refuerza contra fuerza bruta, XSS o escaneos masivos.
  • Copias automáticas diarias con retención (≥14 días) y restauración en 1 clic; idealmente, además, backups externos.
  • Entorno de staging para probar actualizaciones y cambios sin riesgo. Esto no es muy habitual pero algunos proveedores de hosting en España lo ofrecen sin coste adicional.
  • Certificados SSL

Versiones recomendadas (WordPress 6.8+)

  • PHP: 8.3 o superior (8.2–8.4 plenamente soportadas). WordPress.org+1
  • Base de datos: MySQL 8.0+ o MariaDB 10.6+ (compatibles y con LTS en ramas 10.11/11.x).

Fase 1 – Endurecer el core

Mantén WordPress, temas y plugins al día

Siempre que sea posible mantén tus plugins, plantilla y core de WordPress con la última versión disponible. Hacemos mención a “siempre que sea posible” porque hay ocasiones en que algunas actualizaciones de plugins son incompatibles con nuestra plantilla o hacen conflicto entre plugins, en estas ocasiones hay que valorar si es mejor retrasar la implementación de estas actualizaciones o si es preferibles instalarlas y solucionar la incompatibilidad con código a medida.

Salts y llave secreta

En wp-config.php hay ocho constantes llamadas Authentication Unique Keys and SALTs. Son secretos criptográficos que WordPress usa para firmar y validar las cookies de sesión y los nonces (tokens anti–CSRF). No cambian cómo se guarda tu contraseña en la base de datos, pero sí determinan si una cookie o un nonce es válido. Por eso son críticas.  Visita https://api.wordpress.org/secret-key/1.1/salt/, copia las líneas y reemplázalas en wp-config.php. Esto invalida todas las sesiones existentes de golpe.

Prefijo de tabla no estándar

En una instalación nueva cambia el prefijo de las tablas de la base de datos por algo aleatorio. Por defecto WordPress usará el prefijo wp_ en todas sus tablas, esto se puede cambiar cuando se hace la instalación. Si no se trata de una web nueva deberás editar las tablas de tu base de datos manualmente y tu archivo wp-config.php

Permisos de ficheros estrictos

Usa 755 para directorios y 644 para archivos; endurece wp-config.php a 600 (o 400) y evita 777. Puedes ampliar la información sobre este tema en nuestro post específico sobre permisos de archivos y directorios. Una configuración incorrecta de los permisos de archivos y directorios puede provocar problemas de seguridad, de rendimiento y errores en el funcionamiento de tu WordPress

Mover wp-config.php fuera del root (opcional)

Coloca wp-config.php un nivel por encima del directorio público; WordPress lo detecta automáticamente. Esto añade una capa de seguridad al impedir el acceso directo por navegador.

Si quieres mover el wp-config.php a una ubicación personalizada, fuera del root, mantén un “stub” en la raíz y apunta con require_once al wp-config.php definitivo almacenado en una ruta no pública.

Fase 2 – Autenticación y control de acceso

La pantalla de login a tu WordPress es la puerta principal de acceso. En esta fase vamos a reducir al mínimo la superficie de ataque endureciendo identidades y sesiones. El objetivo es que, incluso si una contraseña se filtra o alguien comete un error, los intrusos no consigan entrar.

Usuario admin «por defecto»

Si tu WordPress tiene los usuarios admin, administrator, etc., debes eliminarlos y sustituirlos por un username “aleatorio” (tampoco uses el nombre de tu negocio o tu dominio), esto ayudará a evitar ataques de fuerza bruta.

Principio de menor privilegio

Cada usuario sólo debe tener los permisos estrictamente necesarios.

Usa contraseñas robustas

Longitud ≥ 14 caracteres y gestor de contraseñas

Actualiza tus contraseñas con cierta frecuencia

Debes actualizar todas las contraseñas de tus usuarios con cierta frecuencia (trimestral, mensual, etc.)

Usa 2FA

Existen plugins gratuitos como como WP 2FA, Google Authenticator o Jetpack 2FA

Limite de intentos

Limita el número de veces que puede intentarse un login erróneamente, puedes usar plugins como Limit Login Attempts Reloaded o WAF.

Renombra la ruta de acceso por defecto /wp-admin/

Cambiando la ruta de acceso por otra (te recomendamos que sea lo más “estrambótica” posible) evitarás ataques de fuerza bruta. Esto puedes hacerlo mediante el uso de plugins gratuitos o código a medida.

Desactivar enumeración de usuarios

La enumeración (/?author=1,2…) permite adivinar nombres de usuario y facilitar fuerza bruta. Bloquéala en Apache con:

RewriteCond %{QUERY_STRING} author=\d+

RewriteRule ^ – [F]

Fase 3 – Protección perimetral

WAF

Un WAF filtra tráfico malicioso (fuerza bruta, bots, inyecciones) antes de que llegue a WordPress. Puede usar 2 opciones, WAFen el borde (Cloudflare, Sucuri, Jetpack Security) o en endpoint (plugin como Wordfence).Recomendamos priorizar WAF en el borde por rendimiento y protección DDoS; y usar plugin como capa extra para registros y reglas finas.

Bloquear xmlrpc.php (si no usas apps externas)

Es una puerta común para fuerza bruta, puedes descativarlos en Apache

<Files xmlrpc.php>

order deny,allow

deny from all

</Files>

o desactivarlo desde WordPress
add_filter(‘xmlrpc_enabled’, ‘__return_false’);

Headers HTTP

Son políticas que el servidor envía en cada respuesta para reforzar la seguridad del navegador. Aplícalas en la configuración del servidor o desde tu CDN/WAF, siempre probándolas antes en staging.

  • HSTS: fuerza HTTPS y evita downgrades:
  • Apache: Header set Strict-Transport-Security «max-age=31536000» env=HTTPS
  • Nginx: add_header Strict-Transport-Security «max-age=31536000» always;
  • X-Content-Type-Options: nosniff (evita interpretaciones erróneas).
  • X-Frame-Options: SAMEORIGIN (mitiga clickjacking).
  • Extra (avanzado): Content-Security-Policy y Permissions-Policy; pruébalos en staging para no romper scripts legítimos.

CDN + mitigación DDoS

Usa Cloudflare o similar y cachea recursos estáticos para acortar latencia y absorber picos de tráfico malicioso.

Fase 4 – Copias de seguridad y recuperación

Las copias de seguridad son una de las armas más eficaces y rápidas para recuperar una web tras un ataque o un error humano de desarrollo. Te explicamos cómo organizarlas (no te recomendamos lo de hacer una copia de seguridad cada vez que se nos viene a la cabeza).

  • Estrategia 3-2-1: conserva al menos 3 copias de seguridad (la de producción + 2 copias), en 2 medios distintos (p. ej., servidor y nube), y 1 copia offsite, idealmente offline o inmutable (p. ej., S3 Glacier con Object Lock o un disco desconectado).
  • Revisa que las copias automáticas del servidor se generan correctamente y se pueden utilizar
  • Plugins recomendados para la gestión de copias de seguridad: Jetpack Backup, UpdraftPlus, Duplicator Pro.
  • Recomendaciones:
    • Hacer copia manual tras cada gran cambio.
    • Probar la restauración en un staging antes de subirla a producción.
    • Verificar integridad (hash SHA-256) del ZIP cuando lo descargues.

Fase 5 – Monitorización continua

Monitorizar es poner “sensores” en tu web para detectar cambios anómalos (archivos, malware, caídas, acciones de usuarios) y avisarte al instante por email (u otro canal como Slack), para actuar antes de que el problema impacte al portal y al negocio. Sirve también para centralizar los logs y revisar alertas: lo que no se mide, no se protege. A continuación te mostramos un pequeño ejemplo de sistema de monitorización y avisos:

  • Monitorización de cambios de archivos: mediante el plugin WP File Monitor Plus, integridad Jetpack.
  • Monitorización de Malware: WPScan CLI/script, VirusTotal API
  • Monitorización de caídas: UptimeRobot, Jetpack Monitor
  • Logs de actividad: Activity Log plugin; exporta a Syslog
  • Configura alertas por correo cuando se detecten cambios críticos.

Enlace esencial: te recomendamos guardar en favoritos la referencia oficial del Codex: Fortaleciendo WordPress. Ahí encontrarás muchos de los conceptos que hemos desarrollado en este artículo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *