Una auditoría de seguridad WordPress en 15 pasos: qué mirar, cómo comprobarlo y por qué. Para hacerla tú, y repetirla cada pocos meses.
Temas Endurecimiento y listas de comprobación Guías para principiantes
Actualizado Publicado
Una auditoría de seguridad es un pase ordenado por el sitio: qué hay instalado, quién puede entrar, qué está desactualizado o tiene un fallo conocido, si los archivos cuadran y si las copias de seguridad restauran de verdad. No es un certificado y tampoco es una puntuación para asustar.
Hazla cada pocos meses. Un sitio quieto no se queda quieto: salen actualizaciones, se va un colaborador y se queda su usuario, o el hosting cambia la versión de PHP sin avisar. En una tienda, no esperes al trimestre para mirar administradores y copias.
Si solo quieres tachar casillas, usa la checklist de seguridad. Si el sitio ya está comprometido, deja esta lista y ve a qué hacer en los primeros 60 minutos. La definición corta está en el diccionario: auditoría de seguridad.
Dentro de Security Ninja:
Fuera del plugin: las herramientas de malware del panel del hosting, los problemas de seguridad en Search Console y una visita con el navegador desconectado, porque algunas redirecciones solo las ve quien no ha iniciado sesión.
Los tipos de escáner, y qué cubre cada uno, están en la comparación de escáneres.
Úsalos como orden del día. En un sitio folleto basta con el pase completo cada pocos meses. En tiendas y sitios de membresía, repite cada semana los pasos de acceso, actualizaciones y copias.
Anota cada hallazgo con un responsable y una fecha. Arregla primero lo que deja entrar a alguien. Lo demás puede esperar a la siguiente ventana.
Mira en Escritorio → Actualizaciones. El núcleo, los plugins y los temas tienen que estar en una versión con soporte. Si el sitio es frágil, prueba antes en una copia de pruebas.
Por qué: un plugin o un tema sin actualizar es una de las entradas más habituales. No hace falta un ataque elaborado.
En Plugins y Apariencia → Temas, borra lo desactivado. Un plugin desactivado sigue en disco y se puede explotar igual.
Anota también los que llevan mucho tiempo sin una actualización del autor. Si nadie los mantiene, planifica el reemplazo. No hace falta decidirlo el mismo día, pero sí dejarlo escrito.
En Usuarios, lista a los administradores y a quien pueda instalar plugins. Quita freelancers que ya no trabajan y cuentas que nadie usa. Mira si hay correos o nombres que no reconoces.
El rol de administrador es para quien de verdad administra. Un editor no necesita ese rol para publicar. Más contexto: roles de usuario.
Cada persona con privilegios necesita una contraseña larga, única y guardada en un gestor. Nada de una cuenta compartida llamada admin.
Activa la autenticación en dos pasos en los roles con privilegios. Sin el segundo paso, una contraseña filtrada en otro sitio basta para entrar.
Comprueba que el formulario de acceso no acepta intentos infinitos. Un límite bajo, o un bloqueo temporal, corta la fuerza bruta sin cerrarte la puerta a ti.
Puedes hacerlo desde el hosting o con protección de acceso. La guía larga está en proteger el acceso a WordPress.
En el administrador de archivos del hosting, o por SFTP, los directorios suelen ir en 755 y los archivos en 644. wp-config.php puede ir más cerrado, por ejemplo 600 o 640, si el hosting lo permite. No pongas 777.
wp-config.php tiene la contraseña de la base de datos y las claves. No debe poder descargarse desde el navegador. Si abres https://tudominio.com/wp-config.php y ves código o datos, eso hay que cerrarlo.
En el escritorio, Apariencia → Editor de archivos y Plugins → Editor de archivos dejan cambiar PHP desde el navegador. Si alguien entra como administrador, ese editor le ahorra el paso de subir un archivo.
En wp-config.php, por encima de la línea “That’s all, stop editing”, puedes añadir:
define( 'DISALLOW_FILE_EDIT', true );El sitio sigue funcionando. Solo desaparece ese editor. Las actualizaciones normales no lo necesitan.
Confirma que la copia más reciente terminó y que vive fuera del mismo servidor. Una copia en el mismo disco no sirve si el disco se pierde o si el atacante la borra.
La retención tiene que cubrir una ventana anterior a un incidente. Y una vez, restaura en un sitio de pruebas. Una copia que nunca restauraste es una esperanza, no un plan. La diferencia entre copias y plugins de seguridad está en copias frente a plugins de seguridad (en inglés).
Abre el sitio con http:// y comprueba que salta a https://. El candado tiene que ser válido en la portada, en el acceso y en la página de pago si la hay. Mira también si alguna imagen o script sigue en HTTP: el navegador lo marca como contenido mixto.
Sin HTTPS, las contraseñas viajan en claro por redes que no controlas.
En las herramientas del navegador, pestaña Red, mira la respuesta de la home. Interesan cabeceras como Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options o Content-Security-Policy, y Referrer-Policy.
No bloquean un plugin vulnerable. Sí dificultan algunos abusos del navegador, como meter tu sitio en un iframe. Las pruebas de seguridad avisan si faltan. No hace falta memorizar la lista.
Lanza un escaneo de archivos si el hosting lo ofrece, y el escáner de malware si tienes Pro. Revisa el resultado. Hay falsos positivos, sobre todo en plugins poco habituales pero legítimos.
Si el escaneo encuentra algo activo, o ves redirecciones que tú no pusiste, pasa a limpiar un WordPress hackeado. No sigas con el resto de la auditoría como si nada.
Los archivos de WordPress tienen que coincidir con el paquete oficial de la misma versión. El escáner del núcleo marca modificados, ausentes o inesperados.
Un cambio en wp-includes o en wp-admin casi nunca es tuyo. Un cambio en el tema hijo sí puede serlo. No sustituyas el núcleo a ciegas: no pises wp-config.php ni wp-content.
En wp-config.php, mira $table_prefix. Si sigue siendo wp_, las pruebas te lo van a marcar. Cambiar el prefijo en un sitio que ya funciona es fácil de romper: una tabla que se queda con el nombre viejo y las consultas fallan. Con una copia reciente y soltura en la base de datos, se puede planificar. Si no, déjalo anotado y no lo toques en esta pasada.
En el mismo archivo, en producción WP_DEBUG tiene que estar en false. Un debug.log dentro de wp-content no debe ser público: a veces lleva rutas, consultas y datos que no quieres enseñar.
En el panel del hosting, mira la versión de PHP. Tiene que ser una que el hosting todavía mantiene, y compatible con tu núcleo y tus plugins. Si el panel solo ofrece una versión que WordPress ya marca como antigua, pide el cambio o plantea un traslado.
Aprovecha para anotar cómo entras al panel, al SFTP y a las copias. El día que wp-admin no cargue, esa nota vale más que el informe.
Revisa intentos de acceso fallidos, bloqueos y rachas raras de 404. En el plugin, eso está en el registro de eventos. Si el firewall vive en el hosting o en la CDN, mira también esos registros. La guía de firewalls está en firewalls para WordPress.
Pon en la lista de permitidos las IP de la oficina o de la VPN antes de un viaje, no después de quedarte fuera.
Cierra la pasada con una fecha para la siguiente. Lo que no arregles hoy, escríbelo con el motivo. Si no queda escrito, no existe.
| Prioridad | Ejemplos | Primer movimiento |
|---|---|---|
| P0 | Malware activo, un admin desconocido, hosting bloqueado | Contener y limpiar (eliminar malware) |
| P1 | Vulnerabilidad conocida con exploit público y sin parche | Quitar o sustituir el plugin, y endurecer el acceso |
| P2 | Pruebas de endurecimiento fallidas, contraseñas débiles | Arreglar con la checklist y la guía de endurecimiento |
| P3 | Cabeceras que están bien tener, funciones que no usas | Programarlo. No bloquea un P0 ni un P1 |
Tiene sentido hacerlo tú cuando puedes actualizar plugins, leer la salida de un escáner y restaurar una copia. Conviene contratar una revisión o una limpieza cuando el sitio está comprometido en producción, cuando no te sientes cómodo con el acceso al servidor, o cuando los hallazgos vuelven después de una limpieza.
Auditas, arreglas, programas y repites. Empieza por las pruebas de seguridad, que están en la versión gratuita, junto con vulnerabilidades y el escáner del núcleo. Pro añade el escaneo de malware y los análisis programados. Los planes están en precios.
Si te ha servido, compártelo.
Cada pocos meses en un sitio que cambia poco. En una tienda o un sitio con muchos usuarios, revisa accesos, actualizaciones y copias cada semana, y haz el pase completo cada trimestre. Hazlo también después de un susto, de un cambio de hosting o cuando entra o sale alguien del equipo.
Sí, si puedes entrar en wp-admin y en el panel del hosting, actualizar plugins y comprobar que existe una copia. Los pasos de esta página están pensados para eso. Pide ayuda si no puedes restaurar una copia, si el sitio ya está comprometido o si los hallazgos vuelven después de corregirlos.
No. El escaneo busca archivos sospechosos. La auditoría mira también quién puede entrar, qué está desactualizado, si la copia restaura y si la configuración deja puertas abiertas. El escaneo es uno de los 15 pasos, no el pase entero.
Para el pase y sigue el orden de las primeras horas: modo mantenimiento, avisa al hosting y no borres archivos a ciegas. La guía está en qué hacer si WordPress está hackeado .
