WordPress es el sistema de gestión de contenidos más utilizado del mundo. Su facilidad de uso, extensibilidad y ecosistema de plugins y temas lo han convertido en la opción elegida por más del 43 % de los sitios web en Internet. Pero ese mismo éxito lo ha colocado también en el punto de mira de los atacantes.

Miles de ataques automatizados se producen cada minuto buscando vulnerabilidades conocidas, plugins desactualizados, temas pirateados o simples errores de configuración que pueden abrir la puerta a consecuencias desastrosas: inyección de malware, spam SEO, robo de datos, redirecciones maliciosas, bloqueo completo del sitio o incluso uso de tu servidor como bot en ataques DDoS.

En este artículo repasaremos los siguientes errores de seguridad en WordPress:

  1. 1. Contraseñas débiles y ausencia de una política de contraseñas segura
  2. 2. Plugins y temas desactualizados
  3. 3. Usuario admin por defecto
  4. 4. Uso de plugins y temas de dudosa procedencia (nulled)
  5. 5. Permisos de archivos y carpetas incorrectos
  6. 6. No proteger el archivo wp-config.php
  7. 7. No usar HTTPS o configurarlo mal
  8. 8. No limitar intentos de acceso (login)
  9. 9. Exposición de rutas o archivos sensibles
  10. 10. No hacer copias de seguridad periódicas
  11. 11. Mala gestión de roles y permisos de usuario
  12. 12. Dejar el editor de archivos del panel activo
  13. 13. No bloquear ni limitar el acceso a xmlrpc.php
  14. 14. wp-cron mal configurado o expuesto
  15. 15. Dejar contenido por defecto o plugins/temas sin usar

1. Contraseñas débiles y ausencia de una política de contraseñas segura

Uno de los errores más frecuentes (y más fáciles de solucionar) en WordPress —y en cualquier sistema— es permitir contraseñas débiles o reutilizadas, sin una política clara que las imponga y mantenga en el tiempo.

Esto sigue siendo una de las causas más habituales de accesos no autorizados: basta una sola credencial filtrada o fácil de adivinar para perder el control de toda la instalación.

Lo que se suele hacer

  1. Usar contraseñas como admin, 123456, admin123, qwerty o variantes.
  2. Reutilizar la misma contraseña en WordPress, correo, hosting, panel del proveedor y base de datos.
  3. No cambiar contraseñas tras cambios de rol o rotación del equipo (por ejemplo, un freelance que ya no trabaja en la web).
  4. Compartir contraseñas por correo o WhatsApp y no regenerarlas después.
  5. Mantener usuarios con permisos elevados (administrador/editor) que llevan meses o años sin iniciar sesión.
  6. Permitir contraseñas débiles porque «WordPress deja» (o porque un usuario confirma manualmente que quiere usarla).
  7. No exigir renovación periódica, complejidad mínima o 2FA para cuentas críticas.

Por qué es un problema crítico

Los ataques de fuerza bruta y diccionario se basan en probar combinaciones comunes de usuarios y contraseñas. Herramientas como WPScan, Hydra o suites de pentesting permiten automatizar estos ataques a gran escala, probando cientos de combinaciones por segundo contra miles de sitios.

Además, hoy el riesgo ya no es solo «adivinar» la contraseña: es reutilizar credenciales filtradas. Si alguien usa la misma contraseña en varios servicios y uno se filtra, los atacantes prueban esas combinaciones en WordPress (credential stuffing).

El resultado es simple:

  • Si no hay política de contraseñas, tarde o temprano aparece una contraseña débil.
  • Si no hay controles (bloqueo, 2FA, rotación), esa contraseña termina siendo un punto de entrada.

Solución paso a paso

1. Exigir contraseñas fuertes (y definir una política)

Como base mínima recomendable:

  • Longitud 12 caracteres como mínimo (mejor 16+).
  • Mezcla de letras, números y símbolos.
  • Prohibir contraseñas comunes y patrones previsibles.
  • Para roles críticos: obligatorio 2FA.

Con plugin (lo más práctico):

Con código personalizado (si quieres control fino):

<?php
/**
 * Fuerza una longitud mínima de contraseña en perfil, registro y reset.
 * Ajusta la política según tu proyecto.
 */
add_action( 'user_profile_update_errors', 'wpcom_validar_contrasena', 10, 3 );
add_filter( 'registration_errors', 'wpcom_validar_contrasena', 10, 3 );
add_action( 'validate_password_reset', 'wpcom_validar_contrasena_reset', 10, 2 );
function wpcom_validar_contrasena( $errors, $update = null, $user = null ) {
	if ( ! empty( $_POST['pass1'] ) && strlen( (string) $_POST['pass1'] ) < 12 ) {
		$errors->add(
			'password_too_short',
			__( 'La contraseña debe tener al menos 12 caracteres.', 'textdomain' )
		);
	}
	return $errors;
}
function wpcom_validar_contrasena_reset( $errors, $user_data ) {
	return wpcom_validar_contrasena( $errors, null, $user_data );
}

Consejo: si vas a usar código, conviértelo en MU-plugin y acompáñalo de una política documentada para el equipo.

2. Cambiar credenciales débiles o comprometidas (especialmente administradores)

Audita administradores:

wp user list --role=administrator

Actualiza contraseñas (ejemplo):

wp user update 1 --user_pass='CONTRASENA_FUERTE_AQUI'

Si quieres forzar que el usuario cambie la contraseña en su próximo acceso, usa un plugin de expiración:

3. Activar autenticación en dos factores (2FA)

El 2FA evita que alguien entre aunque tenga tu contraseña.

Plugins recomendados:

Apps compatibles:

  • Authy
  • Google Authenticator

Recomendación práctica: 2FA obligatorio para administradores y cualquier rol con acceso a plugins críticos (seguridad, backups, SEO, formularios).

4. Limitar intentos de acceso (fuerza bruta)

La política de contraseñas debe ir acompañada de un freno a intentos masivos.

Ajuste típico inicial:

  • 3 intentos fallidos → bloqueo 20 minutos
  • Reincidencia → bloqueo prolongado

5. Usar gestores de contraseñas (para que la política sea realista)

Si obligas a contraseñas únicas y largas, el equipo necesita una forma práctica de gestionarlas:

Esto reduce drásticamente la reutilización y el «apunto la contraseña en un sitio inseguro».

6. Auditar usuarios inactivos y accesos heredados

Revisa usuarios con permisos elevados que no deberían seguir existiendo.

wp user list --role=administrator --field=user_login

Para eliminar y reasignar contenido:

wp user delete USUARIO --reassign=ADMIN_ID

Buenas prácticas extra

  • No uses «admin» como nombre de usuario.
  • No reutilices contraseñas entre servicios.
  • No compartas credenciales por correo o mensajería sin cifrado.
  • Documenta la política (mínimos, rotación, 2FA, revocación de accesos).
  • Si hay rotación de proveedores/freelance: cambio de credenciales inmediato.

Con esto no solo solucionas el problema de «contraseñas malas»: conviertes las credenciales en un control sostenible en el tiempo, incluso cuando el equipo cambia o el proyecto crece.

2. Plugins y temas desactualizados

Si hay un principio fundamental en la seguridad de cualquier sistema es este: lo que no se actualiza, se rompe. En WordPress, este principio es especialmente importante. La gran mayoría de las vulnerabilidades explotadas por atacantes no son vulnerabilidades 0-day, sino fallos conocidos para los que ya existe una actualización disponible.

Actualizaciones de plugins

Lo que se suele hacer:

  1. Dejar el core de WordPress en una versión antigua por miedo a romper la web.
  2. No revisar los plugins y temas instalados, incluso los inactivos.
  3. Tener desactivadas las actualizaciones automáticas.
  4. Usar plugins o temas que ya no tienen soporte ni actualizaciones.
  5. Utilizar software nulled o descargado de fuentes no oficiales.

Por qué es un error crítico

WordPress, al ser software libre, tiene su código público. Cuando se detecta una vulnerabilidad y se publica una actualización, esa información también queda disponible para atacantes. Es cuestión de tiempo (a veces minutos) para que scripts automáticos empiecen a escanear la red buscando instalaciones que no hayan aplicado el parche.

En muchos casos, basta un plugin desactualizado para comprometer todo el sitio. Da igual que el core esté actualizado si tienes una versión vulnerable de un plugin activo.

Solución paso a paso

1. Habilitar actualizaciones automáticas seguras

WordPress ya actualiza el core menor (por ejemplo, de 6.4.1 a 6.4.2) por defecto. Pero podemos configurar que también se actualicen los plugins y temas automáticamente.

Desde el functions.php o un plugin de funcionalidades:

add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

Si usas wp-config.php, puedes forzar la actualización del core:

define( 'WP_AUTO_UPDATE_CORE', true );

Consejo: en proyectos críticos, puedes usar staging + monitorización para detectar problemas antes de que impacten en producción.

2. Revisar periódicamente componentes sin soporte

Plugins y temas que no reciben actualizaciones en más de 6-12 meses son candidatos a ser sustituidos.

Con WP-CLI:

wp plugin list --update=available
wp theme list --update=available

Revisa especialmente aquellos con:

  • Menos de 3 actualizaciones al año.
  • Pocos usuarios activos.
  • Comentarios recientes que reportan problemas.

3. Eliminar lo que no se usa

Un plugin o tema desactivado también puede ser vulnerable. Si no lo necesitas:

wp plugin delete nombre-del-plugin
wp theme delete nombre-del-tema

Si prefieres vía panel:

  • Ve a «Plugins» o «Apariencia > Temas»
  • Borra directamente lo inactivo

4. Supervisar cambios con herramientas externas

Puedes recibir alertas de nuevas actualizaciones con:

O automatizarlo vía WP-CLI:

wp plugin list --update=available --format=csv > actualizables.csv

5. Nunca instales software «nulled»

Descargar versiones «gratuitas» de plugins de pago es la mejor forma de tener malware en tu servidor.

Evita:

  • Plugins de fuentes no oficiales
  • Sitios que ofrecen «Premium gratis»
  • Cualquier contenido que no puedas verificar

No solo es inseguro, sino ilegal. Y muchos de estos paquetes incluyen puertas traseras.

Buenas prácticas extra

  • Haz backups antes de actualizar (idealmente automáticos cada noche).
  • Revisa el changelog antes de aplicar versiones mayores.
  • Mantén también actualizado el entorno del servidor (PHP, MySQL, extensiones).
  • Usa staging si es posible, especialmente en tiendas online.

Actualizar no es opcional, es parte esencial del mantenimiento seguro de WordPress.

3. Usuario admin por defecto

Uno de los errores más antiguos pero que aún se repite es dejar el usuario «admin» activo como administrador del sitio. Este nombre de usuario es el primer objetivo en cualquier ataque de fuerza bruta, escaneo o intento de login automatizado.

Usuario admin

Lo que se suele hacer:

  1. Dejar activo el usuario admin incluso si no se usa.
  2. Utilizar combinaciones predecibles como admin123, admin@midominio.com.
  3. No cambiar el nombre de usuario tras una instalación rápida.
  4. No revisar usuarios creados por instaladores automáticos de hosting.

Por qué es un riesgo tan grande

Porque los atacantes ya tienen la mitad del trabajo hecho. Si conocen el nombre de usuario, solo tienen que adivinar o romper la contraseña. Y como «admin» era el nombre por defecto en instalaciones antiguas de WordPress, sigue siendo uno de los más comunes en millones de sitios.

Muchas herramientas automáticas buscan activamente si existe un usuario con ese nombre:

  • A través de la REST API (/wp-json/wp/v2/users/)
  • Vía ?author=1 y similares (/index.php?author=1)
  • Por medio de formularios de login visibles

Solución paso a paso

1. Verifica si existe el usuario admin

Con WP-CLI:

wp user get admin

Si existe y está activo como administrador, deberías reemplazarlo.

2. Crea un nuevo usuario con nombre personalizado

wp user create nombreseguro nombre@correo.com --role=administrator

Usa nombres no triviales: editor.marcos, admin_2026, etc.

3. Transfiere el contenido del usuario admin

Desde el panel:

  • Entra en «Usuarios > Todos los usuarios»
  • Elimina el usuario «admin»
  • Selecciona la opción de asignar contenido existente al nuevo usuario

Con WP-CLI:

wp user delete admin --reassign=nombreseguro

4. Bloquea enumeraciones de usuarios

Evita que puedan descubrir usuarios por REST API o author IDs.

Para la REST API:

add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    return $endpoints;
});

Para peticiones como ?author=1:

En .htaccess:

RewriteCond %{QUERY_STRING} author=([0-9]*)
RewriteRule .* - [F]

O vía Nginx:

if ($query_string ~* "author=\d") {
  return 403;
}

5. Oculta el nombre de usuario en el front-end

Por defecto, WordPress muestra el nombre de usuario en la URL de autor. Podemos cambiarlo desde el perfil del usuario:

  • Editar el usuario
  • Cambiar el campo Alias para mostrar un nombre distinto del login
  • Seleccionar ese alias como visible

Buenas prácticas extra

  • No uses nombres de usuario iguales al nombre mostrado.
  • Usa alias que no revelen el login.
  • Revisa instaladores automáticos: muchos siguen creando admin por defecto.
  • Si usas multisite, aplica estas medidas en cada subsitio.

Eliminar el usuario «admin» es una de las acciones más sencillas y efectivas para cerrar una puerta muy habitual en ataques.

4. Uso de plugins y temas de dudosa procedencia (nulled)

Una de las amenazas más graves (y comunes) en sitios WordPress es la instalación de plugins o temas descargados de fuentes no oficiales. Especialmente peligrosos son los llamados «nulled», versiones modificadas de productos premium que circulan por webs de descargas «gratuitas».

Aunque puedan parecer una solución rápida para ahorrar costes, el riesgo que implican supera con creces cualquier ventaja aparente.

Plugins nulled

Lo que se suele hacer:

  1. Descargar plugins o temas premium desde sitios de torrents, foros o «clubes» de descargas.
  2. Usar herramientas pirata en sitios de clientes «porque lo pidieron».
  3. No validar la fuente de descarga en proyectos heredados.
  4. Desconocer los nombres reales de plugins porque vienen renombrados.
  5. Instalar «plantillas completas» o «paquetes TODO en uno» sin auditar su origen.

Por qué es una amenaza crítica

El software nulled suele venir con «sorpresa»:

  • Puertas traseras (backdoors)
  • Scripts de spam SEO
  • Inyecciones de malware encubierto
  • Redirecciones ocultas
  • Minado de criptomonedas
  • Inclusión en botnets

Peor aún: muchas de estas amenazas permanecen latentes durante semanas para no ser detectadas de inmediato.

Una vez activo, el malware puede:

  • Enviar spam desde tu servidor
  • Robar datos del formulario de contacto o de pago
  • Redirigir a tus usuarios a webs fraudulentas
  • Bloquear el acceso al panel o eliminar backups

Y si Google detecta actividad maliciosa, marcará tu web como insegura en los resultados de búsqueda.

Ejemplos reales de malware en software nulled

  • «Ultimate Addons for Elementor» nulled incluía código para crear usuarios admin ocultos.
  • «Revolution Slider» pirata fue explotado para propagar el malware SoakSoak.
  • Temas populares como Avada o Bridge han tenido versiones nulled con scripts para robar cookies.

Cómo detectar si tienes software potencialmente peligroso

1. Revisa los orígenes de los plugins y temas

Con WP-CLI:

wp plugin list --format=table
wp theme list --format=table

Y comprueba cada uno en:

Si no encuentras información o el plugin tiene nombre genérico («helper-plugin»), sospecha.

2. Busca archivos sospechosos

Muchos plugins nulled incluyen archivos en:

  • wp-content/uploads/
  • wp-includes/js/tinymce/plugins/
  • wp-content/themes/<tema>/images/ con extensiones .ico, .php, .phtml

Ejemplo de escaneo:

find . -type f -name "*.php" | xargs grep base64_decode

O busca funciones sospechosas:

grep -r --include="*.php" "eval(" .

3. Utiliza plugins de seguridad

Plugins como:

Pueden detectar archivos maliciosos o modificaciones en el core.

4. Verifica cambios en el core

Con WP-CLI:

wp core verify-checksums

Esto comprueba si los archivos de WordPress han sido modificados respecto al original.

Qué hacer si encuentras software sospechoso

  1. Haz backup completo inmediato (por si tienes que restaurar).
  2. Desactiva el plugin o tema desde WP-CLI:
wp plugin deactivate nombre
wp plugin delete nombre
  1. Cambia todas las contraseñas de usuarios con rol elevado.
  2. Revisa wp-config.php, .htaccess y tareas cron.
  3. Reinstala WordPress desde cero si hay duda sobre el core.
  4. Sube versiones oficiales desde fuentes fiables.

Dónde descargar con seguridad

Buenas prácticas extra

  • Verifica siempre la URL de descarga y su reputación.
  • Guarda los archivos zip originales junto con el nombre del proveedor.
  • Audita plugins y temas antes de instalar en sitios de clientes.
  • Desinstala lo que no tenga garantía de actualización o soporte.

Evita a toda costa instalar software modificado de fuentes no oficiales. No solo comprometes la seguridad, sino también la reputación de tu web (y la de tu cliente).

5. Permisos de archivos y carpetas incorrectos

Una de las configuraciones más olvidadas (y peligrosas) en instalaciones de WordPress es la de los permisos de archivos y directorios. Si están mal definidos, pueden permitir que un atacante escriba, ejecute o incluso borre archivos críticos del sistema.

Por qué es un fallo grave de seguridad

Los permisos controlan quién puede leer, escribir o ejecutar un archivo o carpeta. Si un archivo con código PHP tiene permisos de escritura para «todos», cualquier plugin vulnerable podría modificarlo e inyectar código malicioso.

Por otro lado, si los permisos son demasiado restrictivos, podrían impedir que el servidor lea archivos necesarios o que WordPress funcione correctamente.

El equilibrio es clave: permisos lo bastante seguros para proteger, pero lo bastante abiertos para permitir el funcionamiento normal del sitio.

Solución paso a paso

En la estructura de permisos de Linux, los permisos se representan como:

drwxr-xr-x  (carpeta)
-rw-r--r--  (archivo)

Equivalente numérico:

  • 7 = lectura + escritura + ejecución (rwx)
  • 6 = lectura + escritura (rw-)
  • 5 = lectura + ejecución (r-x)
  • 4 = solo lectura (r–)

Permisos recomendados para WordPress

Tipo de archivoPermiso recomendado
Archivos (PHP, HTML, etc.)644
Directorios755
wp-config.php640 o 600
.htaccess644 o 600

Nunca uses 777. Es una invitación directa a la explotación.

Comprobación rápida desde consola

find . -type d ! -perm 755
find . -type f ! -perm 644

O para comprobar solo el archivo wp-config.php:

stat -c "%a %n" wp-config.php

Corregir permisos de forma segura

Desde el directorio raíz de la instalación:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

Consejo: asegúrate de que el propietario del archivo es el usuario correcto (por ejemplo, www-data o www)

chown -R www-data:www-data /var/www/html

Evitar ejecución en carpetas sensibles

Especialmente en wp-content/uploads/, que no debería contener ningún archivo ejecutable PHP.

1. Denegar ejecución en .htaccess

<Directory "/ruta/a/wp-content/uploads">
    <FilesMatch ".*\.php$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>

2. O en Nginx:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

3. Eliminar PHP del directorio:

find wp-content/uploads -type f -name "*.php" -delete

Automatizar la verificación

Puedes crear un script de auditoría que revise permisos y te envíe alertas:

#!/bin/bash
SITE_PATH="/var/www/html"
LOG="/var/log/permisos_wp.log"
find "$SITE_PATH" -type d ! -perm 755 >> $LOG
find "$SITE_PATH" -type f ! -perm 644 >> $LOG
stat -c "%a %n" $SITE_PATH/wp-config.php >> $LOG

Y lanzar este script desde cron semanalmente.

Buenas prácticas extra

  • Asegúrate de que wp-config.php no sea escribible ni accesible desde navegador.
  • Nunca uses permisos 777 en producción.
  • Configura alertas si se modifican archivos sensibles.
  • Haz auditorías regulares en sitios que gestionas.

La configuración de permisos es fácil de ignorar, pero puede marcar la diferencia entre un sitio seguro y uno comprometido.

6. No proteger el archivo wp-config.php

wp-config.php es el archivo más sensible de tu instalación WordPress. Contiene:

  • Las credenciales de acceso a la base de datos.
  • Las claves de seguridad (AUTH_KEY, SECURE_AUTH_KEY, etc.).
  • Configuraciones avanzadas del entorno.

Un acceso no autorizado a este archivo equivale a entregar las llaves del sitio. Y sin embargo, muchas instalaciones dejan wp-config.php sin ninguna protección adicional.

Riesgos si no está protegido:

  1. Puede ser descargado si el servidor no interpreta correctamente los archivos PHP.
  2. Plugins maliciosos podrían modificarlo si tiene permisos de escritura.
  3. Puede ser expuesto por errores de configuración del servidor (listas de directorios, rutas mal resueltas).

Solución paso a paso

1. Comprobar que no se puede acceder desde el navegador

Prueba accediendo directamente:

https://tuweb.com/wp-config.php

Debe mostrar un error 403 o 500. Si ves el contenido o una descarga, hay un problema grave.

2. Revisar permisos del archivo

Ejecuta desde la raíz:

stat -c "%a %U:%G %n" wp-config.php

El resultado debería ser algo como:

600 www-data:www-data wp-config.php

Permisos seguros:

  • Linux/Unix: 600 o 640
  • Propietario: el usuario del servidor web (www-data, apache, etc.)

3. Bloquear acceso vía servidor web

Apache / LiteSpeed:

<Files wp-config.php>
    Order allow,deny
    Deny from all
</Files>

Nginx:

location = /wp-config.php {
    deny all;
    return 403;
}

Opciones avanzadas

Mover wp-config.php fuera del document_root

WordPress permite tener wp-config.php un nivel por encima de la carpeta de instalación, por ejemplo:

/home/usuario/wp-config.php
/var/www/html/index.php

WordPress lo detectará automáticamente si está justo encima.

Ventajas:

  • No accesible desde la web incluso si el servidor está mal configurado.
  • Más difícil de detectar por scripts automatizados.

Separar datos sensibles en un archivo extra

Puedes crear secrets.php con las claves y credenciales, y cargarlo desde wp-config.php:

require_once __DIR__ . '/../secrets.php';

Y luego aplicar protecciones más estrictas a ese archivo.

Auditar cambios en wp-config.php

Cualquier modificación en este archivo debería activar una alerta. Puedes usar:

Ejemplo con inotifywait:

inotifywait -m -e modify wp-config.php

O monitorizar cambios con cron + sha256sum:

sha256sum wp-config.php > hash.txt
# luego comparar periódicamente
sha256sum -c hash.txt

Buenas prácticas extra

  • Usa permisos 600/640 y propiedad correcta.
  • Bloquea vía servidor.
  • Evita que plugins escriban en wp-config.php.
  • Monitoriza cambios y guarda copias de seguridad del archivo.

wp-config.php es el corazón de tu WordPress. Cuidarlo es cuidar WordPress.

7. No usar HTTPS o configurarlo mal

Usar HTTPS no es opcional: es un requisito de seguridad y confianza. Sin HTTPS, toda la comunicación entre el navegador del usuario y el servidor puede ser interceptada, modificada o espiada.

Y lo que es peor: los navegadores modernos muestran advertencias visibles en sitios sin HTTPS, lo que impacta negativamente en la percepción de seguridad por parte de tus usuarios.

Errores típicos:

  1. No tener certificado SSL instalado.
  2. Tenerlo instalado, pero no forzar su uso (la web carga tanto en HTTP como en HTTPS).
  3. Enlaces internos que siguen usando http:// en vez de https://.
  4. Mezcla de contenido: CSS, JS o imágenes que se cargan por HTTP en una página HTTPS.
  5. Redirecciones mal configuradas que crean bucles o errores 301/307 incorrectos.

Riesgos de no usar HTTPS:

  • Las credenciales de acceso pueden ser robadas en conexiones abiertas (cafeterías, Wi-Fi público).
  • Los formularios (contacto, login, compra) pueden ser manipulados.
  • Motores de búsqueda como Google penalizan sitios sin HTTPS.
  • Navegadores como Chrome muestran advertencias claras de «sitio no seguro».

Solución paso a paso

1. Instalar un certificado SSL

La opción más popular y gratuita:

Puedes instalarlo:

  • Vía panel de hosting (casi todos los proveedores lo integran)
  • Con Certbot en servidores VPS/dedicados:
sudo apt install certbot
sudo certbot --nginx   # o --apache

2. Forzar HTTPS en todo el sitio

Desde WordPress

En wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

Desde el servidor

Apache / .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx:

server {
  listen 80;
  server_name tuweb.com www.tuweb.com;
  return 301 https://$server_name$request_uri;
}

3. Actualizar enlaces internos

Usa el plugin Better Search Replace para reemplazar todas las referencias http:// por https://:

Haz siempre una copia de seguridad antes.

4. Solucionar contenido mixto

Usa plugins como:

O detecta los errores desde:

5. Activar HSTS (HTTP Strict Transport Security)

Indica a los navegadores que solo deben acceder por HTTPS:

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

El valor preload permite enviar tu dominio a la lista de sitios HTTPS obligatorios en los navegadores.

6. Verifica todo correctamente

Revisa con:

Buenas prácticas extra

  • Usa redirecciones 301 (no temporales) al pasar de HTTP a HTTPS.
  • Asegúrate de que no haya contenido mixto en headers o scripts de terceros.
  • No uses plugins que fuerzan HTTPS por JavaScript: hazlo a nivel de servidor.
  • Renovación automática del certificado con cron o panel.

Pasar a HTTPS es obligatorio en 2026. Hacerlo bien es lo que marca la diferencia entre una implementación profesional y una chapuza.

8. No limitar intentos de acceso (login)

Uno de los vectores de ataque más frecuentes en WordPress son los intentos de acceso no autorizados por fuerza bruta. Si tu sitio permite intentos ilimitados de login, estás exponiendo tu panel de administración a bots que prueban combinaciones de usuario y contraseña sin parar.

Un hosting a prueba de todo

Olvídate de caídas y carga lenta. Tu web, siempre rápida, segura y disponible.

Lo quiero

Aunque uses una buena contraseña, permitir cientos de intentos por minuto no tiene sentido y genera carga innecesaria en el servidor.

Por qué es un riesgo real:

  • Miles de IPs buscan WordPress accesibles para probar credenciales comunes.
  • Si no hay limitación, pueden probar millones de combinaciones.
  • Aumenta el consumo de recursos y puede saturar el servidor.
  • Si una contraseña está comprometida, entrarán sin obstáculos.

Errores habituales:

  1. No usar ningún sistema de limitación de intentos.
  2. Confiar solo en la complejidad de la contraseña.
  3. Permitir el acceso al panel /wp-login.php a todo el mundo 24/7.
  4. No usar ninguna capa de protección adicional como 2FA o WAF.

Solución paso a paso

1. Instalar un plugin para limitar intentos

Algunas opciones sencillas y eficaces:

Estos plugins permiten:

  • Definir número máximo de intentos
  • Bloquear IPs temporal o permanentemente
  • Mostrar mensajes de advertencia
  • Recibir notificaciones de actividad sospechosa

2. Configurar el plugin correctamente

Ejemplo con Limit Login Attempts Reloaded:

  • Intentos permitidos: 3
  • Tiempo de bloqueo: 20 minutos
  • Bloqueo prolongado tras varios fallos: sí
  • Guardar registro de IPs bloqueadas: sí

3. Proteger /wp-login.php con reglas del servidor

Apache (.htaccess):

<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from xx.xx.xx.xx
</Files>

Nginx:

location = /wp-login.php {
    allow xx.xx.xx.xx;
    deny all;
}

O limitar por User-Agent o rate limit:

limit_req zone=login burst=1 nodelay;

4. Activar 2FA (autenticación en dos pasos)

Incluso si logran la contraseña, no podrán acceder sin el segundo factor:

Compatible con apps como Authy o Google Authenticator.

5. Utilizar un Firewall de Aplicaciones Web (WAF)

Servicios como:

  • Cloudflare (modo «I’m under attack»)
  • Sucuri Firewall
  • WAFs integrados en plugins como Wordfence o Solid Security

Permiten bloquear de forma más inteligente los ataques automatizados.

Monitorizar intentos

Puedes revisar los intentos fallidos:

  • En el panel del plugin
  • Desde los logs del servidor (access.log, error.log)
  • Con WP-CLI:
wp user list --fields=login,login_attempts

Buenas prácticas extra

  • No uses «admin» como usuario de login.
  • Cambia la URL de acceso con plugins como WPS Hide Login.
  • Restringe accesos al login a rangos de IP conocidos (si gestionas pocos usuarios).
  • Implementa captcha en el formulario de login y registro.
  • Borra usuarios inactivos o sin uso.

Limitar intentos de login es una barrera de entrada esencial.

9. Exposición de rutas o archivos sensibles

Muchos ataques comienzan simplemente porque el atacante puede ver más de lo que debería. WordPress, por defecto, no protege ciertos directorios ni oculta la estructura del sitio, lo que puede exponer información valiosa sobre plugins, temas, rutas internas o archivos de configuración.

Por qué es peligroso

  • Permite a un atacante saber qué plugins y versiones usas.
  • Expone archivos como readme.txt, .git, composer.json, .env, etc.
  • Facilita ataques dirigidos a versiones vulnerables.
  • Puede revelar configuraciones internas del servidor.

Ejemplos típicos de exposición

Comprobación rápida

1. Directorios listables

Intenta acceder a:

https://tuweb.com/wp-content/plugins/
https://tuweb.com/wp-content/uploads/

Si ves un índice de archivos, hay un problema. Debe devolver un error o una página en blanco.

2. Archivos accesibles

Prueba URLs como:

Si cualquiera devuelve contenido, necesitas intervenir.

Cómo proteger estas rutas

1. Desactivar listado de directorios

Apache (.htaccess):

Options -Indexes

Nginx:

autoindex off;

2. Bloquear acceso a archivos sensibles

Apache:

<FilesMatch "(\.git|\.env|\.htaccess|wp-config\.php|readme\.html|readme\.txt|license\.txt|.*\.log|.*\.bak|.*\.sql|.*\.zip)">
    Require all denied
</FilesMatch>

Nginx:

location ~* \.(git|env|htaccess|log|bak|sql|zip|txt)$ {
    deny all;
}

3. Eliminar archivos innecesarios

Desde la raíz del sitio:

rm -f readme.html license.txt wp-config-sample.php
find . -type f \( -name "*.bak" -o -name "*.sql" -o -name "*.zip" \) -delete

4. Mover archivos de configuración fuera del document_root

Coloca .env, config.php y similares un nivel arriba para evitar accesos accidentales.

5. Bloquear escaneos con WAF

Plugins como Wordfence pueden bloquear escaneos masivos o peticiones a rutas sospechosas:

  • /xmlrpc.php
  • /wp-json/wp/v2/users
  • /?author=1

Y también servicios como Cloudflare pueden ayudarte a bloquear IPs que abusan de este tipo de accesos.

Bonus: cabeceras HTTP para ocultar versión

En functions.php:

remove_action( 'wp_head', 'wp_generator' );

Desde servidor:

Header unset X-Powered-By
Header always unset X-Pingback

Buenas prácticas extra

  • Escanea periódicamente con herramientas como WPScan, Nikto o Nessus.
  • Configura alertas de acceso a rutas sensibles.
  • Revisa los backups y logs públicos accidentalmente subidos.
  • Minimiza el uso de plugins innecesarios que añaden rutas visibles.

No es solo cuánto blindas tu web, sino cuánto permites que se vea desde fuera.

10. No hacer copias de seguridad periódicas

La seguridad no es solo prevenir ataques: también es poder recuperarse rápidamente si algo falla. Y para eso, las copias de seguridad son fundamentales. Aún así, muchísimos sitios WordPress no tienen un sistema de backups fiable, automatizado y probado.

Un error de configuración, un plugin defectuoso, un ataque o incluso un descuido humano pueden dejar una web inservible en segundos. Si no tienes una copia reciente, lo pierdes todo.

Por qué es un fallo crítico

  • Muchos ataques (malware, ransomware) requieren restaurar versiones anteriores.
  • Los errores humanos existen: se pueden borrar entradas, categorías o archivos por accidente.
  • Los plugins o temas pueden generar conflictos o dejar la web en blanco.
  • Las actualizaciones fallidas pueden romper funcionalidades clave.

Errores habituales

  1. No tener ningún sistema de backup activo.
  2. Tenerlo solo en local (en el mismo servidor que la web).
  3. Realizar backups completos pero sin automatizar.
  4. No realizar restauraciones de prueba.
  5. No incluir base de datos y archivos completos.
  6. Guardar las copias en el mismo sitio vulnerable al ataque.

Solución paso a paso

1. Elegir el tipo de backup adecuado

  • Completo: base de datos + archivos. Ideal para backups regulares.
  • Parcial: útil para restauraciones rápidas (solo plugins, solo uploads).
  • Incremental: solo guarda cambios desde la última copia. Más eficiente.

2. Automatizar las copias

Plugins recomendados:

Todos permiten programar backups automáticos diarios, semanales o por hora.

3. Usar almacenamiento remoto

Nunca guardes los backups solo en el mismo servidor. Usa:

  • Google Drive
  • Dropbox
  • Amazon S3
  • pCloud
  • Servidores FTP/SFTP externos

4. Hacer pruebas de restauración

No esperes a tener una crisis para descubrir que la copia no funciona.

  • Prueba al menos una vez al mes restaurar en entorno de staging o local.
  • Verifica que la base de datos, usuarios y contenido estén completos.

5. Copias de seguridad desde el servidor (método manual / avanzado)

Ejemplo con WP-CLI + tar:

wp db export ~/backups/backup-$(date +%F).sql
tar -czf ~/backups/wp-content-$(date +%F).tar.gz wp-content/

Enviar a almacenamiento remoto:

rclone copy ~/backups remote:pcloud/miweb/backups/

Borrar backups antiguos (más de 7 días):

find ~/backups -type f -mtime +7 -delete

6. Considerar backups de servidor completo (nivel hosting)

  • Algunos proveedores hacen backups diarios automáticos (en el caso de WordPress.com se hacen en tiempo real).
  • Ideal si puedes acceder fácilmente al panel y restaurar archivos sueltos o la base de datos.

Buenas prácticas extra

  • Programa backups completos diarios y diferenciales cada pocas horas (si tienes tienda o LMS).
  • Protege tus copias: no dejes archivos .sql o .zip accesibles desde el navegador.
  • Documenta el proceso de restauración y compártelo con tu equipo o cliente.
  • Usa nombres con fecha/hora para identificar las copias.
  • Verifica que los backups se estén generando (no basta con «suponer que están»).

Un backup no probado es como no tener ninguno.

11. Mala gestión de roles y permisos de usuario

WordPress cuenta con un sistema de roles y capacidades que permite asignar a cada usuario solo los permisos necesarios para su trabajo. Sin embargo, en muchas instalaciones se otorgan privilegios excesivos (como administradores para tareas menores), lo que abre puertas innecesarias a posibles fallos de seguridad.

Por qué esto es un problema

  • Un colaborador con permisos de administrador puede instalar plugins maliciosos sin saberlo.
  • Si una cuenta con privilegios altos es comprometida, el atacante obtiene control total.
  • Los roles por defecto no se ajustan siempre a las necesidades reales del proyecto.
  • Algunas funciones sensibles no están restringidas adecuadamente (acceso a SEO, backups, etc.).

Errores comunes

  1. Asignar a todos los editores o colaboradores el rol de administrador.
  2. No revisar ni revocar usuarios antiguos o que ya no colaboran.
  3. Instalar plugins sin controlar qué permisos añade.
  4. No usar roles personalizados cuando el proyecto lo requiere.
  5. Permitir registros abiertos sin validación ni restricción de rol.

Sistema de roles de WordPress

Por defecto, WordPress define:

  • Suscriptor: solo gestiona su perfil.
  • Colaborador: puede escribir pero no publicar entradas.
  • Autor: puede escribir y publicar sus propias entradas.
  • Editor: puede gestionar contenido de otros.
  • Administrador: control total del sitio.

Para tiendas WooCommerce se añaden:

  • Customer
  • Shop Manager

Recomendaciones

1. Revisa periódicamente los usuarios activos

Ve a:

Usuarios > Todos los usuarios
  • ¿Hay usuarios inactivos? Elimínalos o desactívalos.
  • ¿Hay roles mal asignados? Corrígelos.

2. Usa un plugin para gestionar roles personalizados

Plugins recomendados:

Permiten:

  • Crear roles nuevos (ej: «Redactor SEO», «Soporte Técnico»)
  • Ajustar capacidades de cada rol
  • Restringir accesos por plugin o menú

3. Bloquea acceso innecesario a funciones críticas

Algunos plugins exponen configuraciones sensibles a todos los administradores. Usa:

4. Desactiva el registro abierto si no es necesario

Ve a:

Ajustes > Generales > Miembros

Y desmarca «Cualquiera puede registrarse» salvo que tengas una razón clara.

5. Audita cambios de permisos o inicios de sesión

Plugins:

O desde WP-CLI:

wp user list --role=administrator

Buenas prácticas extra

  • Evita el uso compartido de cuentas.
  • Usa 2FA en cuentas con acceso al admin.
  • Nombra los roles de forma descriptiva si creas personalizados.
  • Documenta quién tiene acceso a qué.

Con una gestión adecuada de permisos, puedes minimizar riesgos sin frenar el trabajo en equipo.

12. Dejar el editor de archivos del panel activo

WordPress incluye por defecto un editor de archivos en el panel de administración que permite modificar directamente los archivos de plugins y temas desde el navegador. Aunque pueda parecer útil para ajustes rápidos, representa un riesgo de seguridad importante.

Editar plugins

Por qué es peligroso

  • Si un atacante compromete una cuenta con acceso al admin, podrá inyectar código malicioso directamente.
  • Cualquier error de sintaxis al editar archivos puede dejar la web totalmente inoperativa.
  • No hay control de versiones ni entorno seguro para probar cambios.
  • Los cambios se aplican en caliente sin validación ni backup previo.

Errores comunes

  1. Dejar activo el editor aunque no se use.
  2. Usarlo para hacer ajustes directamente en producción.
  3. No tener control de qué usuarios acceden a esa funcionalidad.
  4. No hacer backups antes de modificar archivos.

Solución paso a paso

1. Desactivar el editor desde wp-config.php

La forma correcta de bloquear el editor:

define( 'DISALLOW_FILE_EDIT', true );

Esto oculta el menú de edición de temas y plugins dentro del panel de WordPress.

2. Opcional: bloquear también la instalación de plugins/temas desde el panel

define( 'DISALLOW_FILE_MODS', true );

Esta opción solo debes usar si no quieres que se puedan instalar ni actualizar plugins desde el panel. Ideal para entornos gestionados.

3. Usar otros métodos para editar archivos

  • FTP/SFTP con FileZilla o Cyberduck
  • Acceso directo por terminal (SSH)
  • Editor código local + sistema de versiones (Git)
  • WP-CLI para actualizaciones o cambios controlados

4. Auditar si el editor ha sido usado

Busca rastros en:

  • Los logs del servidor (access.log)
  • Plugins como WP Activity Log o Simple History
  • Archivos modificados recientemente (wp-content/themes/tu-tema/) con ls -lt

Buenas prácticas extra

  • Elimina el editor aunque seas el único administrador.
  • Usa entornos de staging para probar cambios.
  • Documenta cualquier cambio en el código para futuras revisiones.
  • Controla el acceso por roles, no des permisos de más.

Eliminar el editor es una de las primeras acciones que deberías realizar al poner en marcha una instalación segura de WordPress.

13. No bloquear ni limitar el acceso a xmlrpc.php

El archivo xmlrpc.php fue creado para permitir que aplicaciones externas interactúen con WordPress: apps móviles, servicios de publicación remota, pingbacks, trackbacks, etc. Sin embargo, hoy en día es una de las puertas de entrada más atacadas, y en la mayoría de webs modernas ya no es necesario.

Bloquear xmlrpc

Por qué es un problema

  • Se usa para ataques de fuerza bruta distribuidos.
  • Puede saturar el servidor mediante múltiples llamadas remotas.
  • Permite el método system.multicall, que lanza cientos de peticiones en una sola llamada.
  • Suele estar activo aunque no se utilice.

¿Necesitas xmlrpc.php?

Solo si:

  • Usas la app oficial de WordPress para móviles.
  • Tienes un servicio externo (IFTTT, Zapier, etc.) que lo necesita expresamente.
  • Aún dependes de sistemas antiguos de pingbacks.

Si no lo usas (como ocurre en la mayoría de los sitios actuales), lo mejor es bloquearlo o limitarlo severamente.

Comprobación rápida

Accede a:

https://tusitio.com/xmlrpc.php

Si ves el mensaje:

XML-RPC server accepts POST requests only.

…significa que está activo y responde.

Opciones para bloquearlo

1. Desde .htaccess (Apache)

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

2. Desde Nginx

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

3. Con plugins

4. Solo permitir desde IPs concretas

Si realmente lo necesitas, pero solo desde una app concreta:

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
    Allow from xx.xx.xx.xx
</Files>

Bonus: bloquear ataques al método system.multicall

Con el plugin Wordfence puedes bloquear este método específico sin bloquear completamente xmlrpc.php.

También puedes usar un WAF (Cloudflare, Sucuri) para detectar patrones de ataque a xmlrpc.php y bloquearlos automáticamente.

Buenas prácticas extra

  • Si usas REST API y Gutenberg, no necesitas xmlrpc.php.
  • Monitoriza accesos sospechosos desde access.log:
grep "xmlrpc.php" /var/log/apache2/access.log
  • Automatiza el bloqueo de IPs que lo abusen con fail2ban o mod_security.

Cerrar esta puerta reduce en gran medida el ruido de ataques automatizados sobre tu web.

14. wp-cron mal configurado o expuesto

wp-cron.php es el sistema de tareas programadas de WordPress. Ejecuta eventos como publicaciones programadas, envíos de correos o limpiezas automáticas. Sin embargo, su funcionamiento por defecto puede afectar tanto al rendimiento como a la seguridad del sitio si no se gestiona correctamente.

Cómo funciona por defecto

Cada vez que alguien visita tu sitio, WordPress verifica si hay tareas pendientes en wp-cron.php. Si las hay, las ejecuta en ese momento. Esto tiene problemas evidentes:

  • En sitios con poco tráfico, las tareas se acumulan y no se ejecutan.
  • En sitios con mucho tráfico, puede generar llamadas concurrentes a wp-cron.php, saturando CPU y base de datos.
  • Es vulnerable a ataques de bots que fuerzan la carga repetitiva de wp-cron.php.

Errores comunes

  1. Dejar wp-cron.php activo por defecto en sitios de alto tráfico.
  2. No ejecutar cronjobs reales en servidores con acceso a terminal.
  3. Permitir el acceso libre a wp-cron.php desde cualquier IP.
  4. No limitar la frecuencia de ejecución.

Solución paso a paso

Revisa el tráfico a wp-cron.php desde tus logs:

grep "wp-cron.php" /var/log/apache2/access.log

Si hay muchas peticiones repetidas, necesitas optimizarlo.

1. Desactivar el cron por defecto de WordPress

En wp-config.php añade:

define( 'DISABLE_WP_CRON', true );

Esto evita que se ejecute en cada carga de página.

2. Crear un cronjob real en el sistema operativo

Linux (crontab -e):

*/5 * * * * curl -s https://tusitio.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Ejecuta tareas cada 5 minutos desde el servidor, de forma controlada.

3. Proteger el acceso a wp-cron.php

Apache (.htaccess):

<Files wp-cron.php>
    Order Deny,Allow
    Deny from all
    Allow from xx.xx.xx.xx
</Files>

Nginx:

location = /wp-cron.php {
    allow xx.xx.xx.xx;
    deny all;
}

Reemplaza xx.xx.xx.xx con la IP de tu servidor si usas cron externo.

4. Alternativa con WP-CLI

Puedes ejecutar las tareas manualmente:

wp cron event run --due-now

Ideal para sitios de staging o mantenimiento programado.

Plugins útiles

Buenas prácticas extra

  • Nunca dejes wp-cron.php activo en sitios con tráfico alto o WooCommerce.
  • Revisa tareas cron huérfanas o fallidas.
  • Audita plugins que crean tareas cron excesivas.
  • Protege el endpoint con Cloudflare o firewall si no puedes restringir por IP.
  • Documenta las tareas críticas que dependen del cron (envíos de pedidos, suscripciones, etc.).

Un wp-cron.php mal gestionado no solo puede ralentizar tu web, sino abrir puertas a ataques automatizados.

15. Dejar contenido por defecto o plugins/temas sin usar

Una instalación fresca de WordPress viene con contenido y elementos de ejemplo: entradas como «Hello World», la página «Sample Page», el plugin Hello Dolly y varios temas por defecto. Muchos usuarios olvidan eliminarlos, y a lo largo del tiempo, se acumulan también plugins o temas no utilizados.

Esto parece inofensivo, pero representa varios problemas de seguridad y rendimiento.

Temas sin uso

Por qué es un riesgo

  • El contenido por defecto revela que el sitio no ha sido configurado adecuadamente.
  • Temas o plugins sin uso siguen teniendo código ejecutable o accesible.
  • Plugins o temas desactivados pero vulnerables pueden ser explotados si no están actualizados.
  • Se desperdician recursos en el escaneo y mantenimiento de software que no se necesita.

Errores frecuentes

  1. Dejar la entrada «Hello World» y páginas de ejemplo publicadas.
  2. No borrar temas antiguos al cambiar de plantilla.
  3. Tener varios plugins desactivados que no se van a volver a usar.
  4. Instalar y probar plugins/temas desde el admin y dejarlos sin limpiar.
  5. Mantener themes desactualizados por si acaso.

Cómo revisarlo y solucionarlo

1. Eliminar contenido de ejemplo

Desde el panel de WordPress:

  • Ve a Entradas > Todas las entradas y borra «Hello World».
  • Ve a Páginas > Todas las páginas y borra «Sample Page».
  • Revisa los comentarios por defecto y bórralos también.

2. Borrar temas que no uses

En Apariencia > Temas, deja solo el tema activo y como mucho uno secundario actualizado para pruebas.

Para borrarlos desde WP-CLI:

wp theme delete twentyseventeen twentynineteen twentytwentyone

3. Borrar plugins inactivos

Desde el panel de plugins, filtra por «Inactivos» y elimina los que no uses.

WP-CLI:

wp plugin delete hello akismet old-plugin-name

4. Evitar instalaciones desde el admin en producción

  • Usa entornos de staging para pruebas.
  • Sube y activa solo los plugins definitivos.
  • Documenta los cambios y razones por las que se añade un plugin o tema.

5. Revisar manualmente carpetas

En wp-content/themes/ y wp-content/plugins/ pueden quedar restos de pruebas o backups manuales:

ls -lh wp-content/themes/
ls -lh wp-content/plugins/

Elimina cualquier carpeta que no forme parte de la instalación activa o actualizada.

Buenas prácticas adicionales

  • Añade a tu checklist de puesta en marcha la limpieza de contenido de ejemplo.
  • Revisa cada trimestre los plugins y temas instalados y si siguen siendo necesarios.
  • Automatiza alertas para detectar plugins desactivados pero sin actualizar.
  • Haz un backup antes de eliminar temas o plugins por si necesitas recuperarlos.

Una instalación limpia y sin residuos es una instalación más segura, más fácil de mantener y menos vulnerable.

El hosting que te lleva lejos

Rendimiento sin límites, seguridad inquebrantable y fiabilidad garantizada. Tu web, lista para cualquier desafío.

Quiero llegar lejos

Conclusiones

Hemos visto ya los errores más frecuentes a nivel conceptual y técnico que afectan a WordPress: contraseñas inseguras, permisos incorrectos, malas prácticas en el uso de plugins o cron mal gestionado, entre otros muchos. Pero aún queda camino por recorrer.

En la segunda parte del artículo abordaremos temas más avanzados que, aunque menos evidentes, pueden comprometer la seguridad de tu sitio: accesos a archivos ocultos, ejecución de PHP en rutas no esperadas, exposición de la REST API, configuración insegura de cabeceras HTTP, backups mal almacenados y mucho más.

Además, cerraremos con una checklist completa y descargable para que puedas auditar tu instalación paso a paso.