Seguridad WordPress para empresas y agencias

WordPress mueve más del 40 % de todas las webs del mundo y cualquier empresa que lo use es un objetivo por pura probabilidad estadística, sea cual sea su tamaño.

Usar el software más extendido del planeta significa compartir también sus vulnerabilidades conocidas con la mitad de tus competidores.

Y esto no es solo un problema técnico, pues una brecha que exponga datos de clientes activa obligaciones legales concretas (en España, informar a la Agencia Española de Protección de Datos en un plazo de 72 horas), además de los costes de reputación y de recuperación del propio incidente.

Esta guía está organizada teniendo en cuenta por donde entran los distintos posibles ataques, que son cuatro grandes puertas, y en cada una encontrarás cómo entra el ataque, qué lo cierra (con soluciones gratuitas siempre que existen, que es casi siempre) y cómo comprobar que la puerta quedó cerrada.

Después encontrarás tres bloques transversales de distinta afectación, como son los riesgos propios de vender con WooCommerce, lo que te exige la ley aunque nadie te ataque, y el protocolo si ya han entrado.

Dicho todo esto, empezamos.

Puerta 1 – Las extensiones: por donde entra la inmensa mayoría de los ataques

El ataque típico contra un WordPress de empresa no lo lanza una persona contra tu web, lo lanza un bot contra millones de webs a la vez. El proceso es siempre parecido:

1. El bot rastrea internet buscando versiones concretas de plugins con vulnerabilidades publicadas.
2. Identifica la tuya por la huella que deja en el código fuente.
3. Explota el fallo (para el que suele existir exploit automatizado desde el mismo día del aviso).
4. Sube un pequeño archivo PHP a la carpeta de uploads que le da control remoto.
5. Crea un administrador con nombre discreto y empieza a inyectar redirecciones o spam SEO.

Tú no ves nada hasta que Google marca la web como comprometida o un cliente pregunta por qué al hacer clic en tu enlace acaba en una tienda de medicamentos que no es la tuya. Entre la infección y el descubrimiento pasan normalmente semanas.

Los números explican por qué esta puerta es la primera, y es que de todas las vulnerabilidades nuevas de WordPress la mayoría son del tipo XSS, que permite colar scripts ajenos en el navegador de tus visitantes.

Muy típico es el caso de los plugins abandonados, que no dejan de funcionar de golpe, siguen activos, y cada mes sin actualizarse acumulan más probabilidades de tener un fallo conocido que ya nadie va a parchear.

Y hay un agravante que es que WordPress.org cierra o retira plugins del repositorio con cierta regularidad por malware o vulnerabilidades sin corregir, y ese cierre no desinstala nada de tu servidor. El código sigue ahí, ejecutándose, y el aviso no te llega a ningún sitio salvo que lo busques activamente.

Esto mismo le pasó a un cliente mío con un plugin sencillo, una utilidad para mostrar imágenes del antes y el después, pero con una vulnerabilidad enorme, para la que me tocó preparar un parche, ante el abandono del plugin original.

Qué cierra esta puerta:

• Una política de actualizaciones por escrito: gratis y más eficaz que cualquier herramienta, con actualizaciones automáticas para versiones menores y plugins de confianza, prueba en staging para versiones mayores y plugins críticos (pasarela de pago, formularios, membresías), y cobertura semanal fija con copia de seguridad previa para todo lo demás.
• Una auditoría periódica de todo lo instalado: quién mantiene cada plugin y tema, cuándo se actualizó por última vez, si tiene vulnerabilidades conocidas en tu versión (consúltalo gratis en WPScan o Patchstack antes de instalar nada nuevo) y qué duplicidades funcionales puedes eliminar.
• Tolerancia cero con lo nulled o de procedencia desconocida, y decisión inmediata sobre cualquier extensión activa sin actualizaciones disponibles porque el desarrollador desapareció o la licencia caducó, pues eso es código congelado y sin parches, una decisión estratégica y no un detalle técnico.
• Desinstalar lo que no se usa, incluidos los temas de repuesto que se quedan «por si acaso», porque un tema desactivado sigue siendo código explotable presente en el servidor.
• Vigilancia diaria de los cierres del repositorio: Esta detección automática es, hoy por hoy, casi exclusiva de Vigilante, que consulta la API de wordpress.org cada día por cada plugin instalado, activo o no, y avisa con fecha y motivo si alguno ha sido cerrado o retirado.
• Un cortafuegos de aplicación como red de contención, activo desde el primer día aunque sea con la configuración por defecto, con esto bloqueas los patrones de explotación más comunes y la ejecución de PHP en la carpeta de uploads, de modo que frena el ataque incluso cuando el plugin vulnerable siga instalado.
• Ponérselo más difícil al escaneo automatizado: ocultar la versión de WordPress del código fuente, los feeds y las URL de scripts, y eliminar los readme.html y license.txt de la raíz, que la revelan a cualquiera.
• Si el tema es a medida, comprobar que usa tema hijo (un padre modificado directamente pierde los cambios en la próxima actualización) y que está claro quién paga y renueva cada licencia, además, documenta esa revisión con un informe como el que genera la auditoría de temas, te da la referencia para la siguiente.

Cómo comprobar que está cerrada:

• Abre el código fuente de tu portada y busca generator y ver=: si aparece tu versión exacta de WordPress, sigue visible.
• Sube un archivo PHP de prueba a la carpeta uploads por el medio que uses habitualmente e intenta ejecutarlo desde el navegador, debería devolver un error, no ejecutarse.
• Fecha de la última auditoría de extensiones y número de plugins desinstalados en ella: si la respuesta es «nunca» y «cero», ahí tienes el primer hueco.
• Comprueba que tu escáner de integridad tiene programada una exploración automática y cuándo fue la última.

Puerta 2 – Las personas y sus credenciales

La segunda puerta ni siquiera necesita una vulnerabilidad y es que WordPress regala por defecto la lista de nombres de usuario, puesto que su misma API REST responde en tudominio.com/wp-json/wp/v2/users a cualquiera que pregunte, y las URL del tipo ?author=1, ?author=2 redirigen al archivo público de cada autor.

Con esa lista y las colecciones de contraseñas filtradas que circulan por internet, un bot solo tiene que probar combinaciones en tu formulario de acceso, y si XML-RPC está activo puede probar cientos por petición gracias a su método system.multicall.

La otra variante ni siquiera requiere bots. Es el típico caso de la agencia de hace dos años que conserva un acceso de administrador, la cuenta compartida entre tres personas, el ex-compañero al que nadie dio de baja. El error humano, no un ataque brillante, es la causa más habitual de una brecha.

Qué cierra esta puerta:

• Identificación en dos pasos (2FA) obligatoria para todos los perfiles de editor para arriba, con aplicación de verificación (TOTP) o código por email, exigible por perfil desde tu plugin de seguridad.
• Mínimas capacidades con los perfiles por defecto (administrador, editor, autor, colaborador, suscriptor), creando un perfil a medida antes que subir a nadie a administrador por comodidad.
• Caducidad de contraseñas con historial que impida reutilizar las últimas, sobre todo en administradores, y límite de sesiones simultáneas por usuario si trabajas con externos que entran y salen de proyectos.
• Cierre de la enumeración y del XML-RPC desde tu plugin de seguridad o con código, y URL de acceso personalizada en lugar de /wp-login.php, que elimina la mayoría del tráfico automatizado contra el formulario.
• Un gestor de contraseñas con espacios compartidos por equipos (Bitwarden, por ejemplo, tiene versión gratuita para empezar y planes de equipo económicos), que acaba con las contraseñas en hojas de cálculo y en hilos de correo.
• Una lista de bajas para cuando alguien deja la empresa o termina un proyecto, donde reflejar quién tiene/tenía acceso a WordPress, panel del hosting, registrador del dominio, CDN, Search Console y cualquier servicio conectado. Un usuario por persona, con nombre real, o esta lista será imposible de aplicar.
• Un registro de auditoría que capture accesos, cambios de usuarios y activación de plugins, filtrable y exportable. Esto es lo que convierte «alguien tocó algo» en «este usuario hizo esto a esta hora».
• Formación básica del equipo: no reutilizar contraseñas, desconfiar de enlaces y adjuntos inesperados, saber a quién avisar ante algo raro, es gratis, y más rentable que cualquier herramienta.

Cómo comprobar que está cerrada:

• Visita por tu cuenta dominio.com/wp-json/wp/v2/users y dominio.com/?author=1: ninguna de las dos debería revelar nombres de usuario.
• Cuenta cuántos administradores hay y asegúrate, uno a uno, que de verdad lo necesitan.
• Busca cuentas sin acceso en los últimos seis meses y accesos de proyectos ya cerrados.
• Haz el simulacro de baja: si una persona concreta se fuera mañana, ¿cuántos servicios habría que tocar y tienes la lista?

Puerta 3 – El alojamiento y el servidor

La tercera puerta está fuera de WordPress. Aquí hablamos de que, por ejemplo, una versión de PHP al final de su vida útil deja de recibir parches de seguridad aunque todo lo demás esté al día.

Muy típico es también utilizar un hosting compartido sin aislamiento entre cuentas, lo que convierte el ataque al vecino en un ataque a tu web.

Otro caso habitual es un listado de directorios abierto, lo que permite a cualquiera pasearse por /wp-content/uploads/ y descargar lo que encuentre, y lo mismo pasa con permisos de archivo demasiado generosos, que dejan que un proceso comprometido escriba en wp-config.php o .htaccess, los dos archivos donde una sola línea inyectada sobrevive incluso a reinstalar WordPress.

Y hay un problema más en esta puerta, la disponibilidad, porque una caída también es un incidente y cuesta dinero. Según los cálculos que hice para una conferencia que di en GoDigital de Valencia en 2025, un e-commerce pequeño pierde entre 50 y 200 € por minuto caído, una web corporativa entre 20 y 50 contactos comerciales por hora, y un restaurante sin sistema de reservas entre 500 y 1.500 € por noche.

El día que tu web salga en televisión o una campaña funcione de verdad, la diferencia entre un hosting que escala y uno que se cae es facturación directa.

Qué cierra esta puerta:

• Un hosting que cumpla los mínimos exigibles: HTTP/2 o HTTP/3, versiones de PHP y MySQL o MariaDB actualizadas y cambiables por ti sin tiques de soporte, configuración de seguridad específica para WordPress, aislamiento real de cuentas incluso en planes compartidos, soporte técnico especializado en WordPress, recuperación automática ante caídas y capacidad de absorber picos de tráfico. Si el tuyo no los cumple cambiar de hosting es la medida de seguridad más rentable de esta sección.
• Tres constantes en wp-config.php (primer bloque de código más abajo): desactivan el editor de archivos, fuerzan HTTPS en el escritorio y evitan que los errores de PHP se muestren a los visitantes.
• HTTPS en todo el sitio con HSTS (segundo bloque de código de abajo), para que el navegador ni siquiera intente la conexión sin cifrar la próxima vez.
• El resto de cabeceras de seguridad (Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), que puedes generar listas para Apache, Nginx o PHP con este generador de cabeceras gratuito.
• Permisos de archivo correctos: 644 para archivos, 755 para directorios, y 440 o 400 para wp-config.php si el hosting lo permite sin romper nada, además de Options -Indexes en el .htaccess para cerrar el listado de directorios.
• Un security.txt en /.well-known/ siguiendo el estándar RFC 9116, para que un investigador que encuentre un fallo sepa cómo avisarte de forma responsable en vez de publicarlo.
• Vigilancia de integridad de wp-config.php y .htaccess: tu plugin de seguridad debería guardar una copia de referencia con suma de verificación y avisarte con un diff línea a línea si algo cambia sin que hayas sido tú.
• Copias de seguridad verificadas y fuera del servidor: restaura una de prueba en un entorno aparte antes de necesitarla en serio, porque una copia alojada en la misma máquina que protege no vale nada el día que esa máquina falle.
• Monitorización de disponibilidad externa, para enterarte tú antes que tus clientes: servicios gratuitos como UptimeRobot comprueban la web cada cinco minutos y avisan por correo en cuanto deja de responder.

// Desactivar el editor nativo de plugins y temas
define( 'DISALLOW_FILE_EDIT', true );
 
// Forzar HTTPS en wp-admin
define( 'FORCE_SSL_ADMIN', true );
 
// Nunca mostrar errores a visitantes, solo registrarlos
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
 
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

El reparto de responsabilidad con tu hosting conviene confirmarlo por escrito, porque la letra pequeña cambia mucho de un proveedor a otro:

Cómo comprobar que está cerrada:

• Pasa un análisis externo de cabeceras y exposición: el análisis de seguridad hace más de 30 comprobaciones gratis y al instante, sin instalar nada.
• Pregunta a tu hosting, por escrito, qué versión de PHP ejecutas y hasta cuándo recibe parches de seguridad.
• Restaura un backup de prueba en un entorno aparte al menos una vez por semestre y anota cuánto tardaste y si todo se restauró perfecto.
• Recuerda la última caída: ¿te avisó tu monitorización o te avisó un cliente?

Puerta 4 – El perímetro: dominio, correo y proveedores

La cuenta del registrador del dominio sin identificación en dos pasos es el secuestro perfecto pues quien la controle cambia las DNS y se lleva tu web, tu correo y tu marca a otro servidor, con tu WordPress intacto y perfectamente asegurado en el hosting de siempre.

El correo del dominio es la variante silenciosa ya que WordPress y WooCommerce envían correos transaccionales a diario, y un dominio sin DMARC puede ser suplantado por cualquiera para hacer phishing a tus propios clientes con tu remitente y tu marca, sin tocar un solo archivo tuyo.

Los proveedores externos (la agencia, el desarrollador puntual, el servicio conectado por API) son accesos más que habituales que rara vez están inventariados.

Qué cierra esta puerta:

• 2FA y bloqueo de transferencia en el registrador del dominio, hoy mismo: es la cuenta más valiosa de toda tu infraestructura y suele ser la menos protegida.
• Inventario de quién controla qué: dominio, zonas DNS, correo y cada servicio conectado, con un responsable con nombre por fila. Vale una hoja de cálculo, lo que no vale es que la respuesta sea «creo que lo llevaba el informático anterior».
• SPF, DKIM y DMARC en el dominio: el SPF declara qué servidores pueden enviar correo en tu nombre, el DKIM firma cada mensaje (lo genera tu proveedor de correo desde su panel, no es un registro que puedas copiar de una guía) y el DMARC dicta qué hacer con lo que no pase esas comprobaciones. Empieza con el DMARC en modo observación y endurece cuando los informes vengan limpios; tienes los registros de ejemplo más abajo.
• Registro de licencias con titular y fecha de renovación de cada tema y plugin de pago: una licencia que caduca sin que nadie lo sepa es código congelado, y eso te devuelve directo a la puerta 1.
• Acceso de proveedores por escrito: qué puede tocar cada uno, con qué cuenta y hasta cuándo, revocable el día que termina el proyecto. Esto además conecta con el contrato de encargo de tratamiento del bloque legal.

Registros de ejemplo, adaptando dominio y proveedor de correo a los tuyos:

; SPF: declara quien puede enviar correo por ti
; (el include depende de tu proveedor: este es el de Google Workspace)
tudominio.com.  TXT  "v=spf1 include:_spf.google.com ~all"
 
; DMARC, fase 1: solo observar, nada se bloquea todavia
; (recibiras informes de quien envia correo usando tu dominio)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
 
; DMARC, fase final tras unas semanas de informes limpios
; (p=quarantine como paso intermedio si prefieres endurecer poco a poco)
_dmarc.tudominio.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Cómo comprobar que está cerrada:

• Consulta tu registro DMARC con cualquier comprobador gratuito (MXToolbox o dmarcian, por ejemplo): si no existe es que tu dominio es suplantable desde ayer.
• Entra en la cuenta del registrador y verifica dos cosas: que pide segundo factor y que el bloqueo de transferencia está activo.
• Abre el inventario de accesos y licencias: si no existe, esa es la tarea urgente de esta semana.

Tiendas online con WordPress – Riesgos específicos de WooCommerce

El ataque más frecuente contra un WooCommerce pequeño no busca robarte, busca usarte. Me refiero a bots que prueban tarjetas robadas en tu pasarela de pago (lo que se conoce como card testing) haciendo cientos de micropedidos que a ti te generan comisiones por transacción fallida, disputas y, si se acumulan, la suspensión de la cuenta en la pasarela.

La segunda variante es el registro masivo de cuentas falsas, que ensucia tu base de clientes y prepara fraudes posteriores.

Y la tercera no es un ataque sino una acumulación. Cada pedido guarda datos personales, y una base con años de pedidos completos es superficie expuesta el día de una brecha y responsabilidad directa ante el RGPD.

Qué lo cierra, todo gratis:

• Verificación antibots en el pago y el registro: Cloudflare Turnstile es gratuito y menos molesto que un captcha clásico, y la mayoría de plugins de formularios y de seguridad lo integran.
• Límite de intentos de pago por IP y por sesión, desde el cortafuegos de tu plugin de seguridad o desde la propia pasarela, que suele incluir reglas antifraude configurables sin coste.
• Revisión semanal de patrones de fraude: rachas de pedidos fallidos de importe mínimo, muchas cuentas nuevas sin compra asociada, picos de registro a horas extrañas.
• Retención de datos con caducidad: WooCommerce trae herramientas de limpieza y anonimizado en «Ajustes → Cuentas y privacidad». Configúralas y deja de acumular pedidos identificables de hace cinco años que ya no necesitas.

Cómo comprobar que está cerrada:

• Consulta en el panel de tu pasarela la proporción de transacciones rechazadas del último mes: si supera con claridad a la de meses anteriores, ya te están usando.
• Cuenta las cuentas de cliente creadas en los últimos 30 días sin ningún pedido asociado.
• Abre un pedido de hace tres años y mira qué datos personales sigue guardando.

Obligaciones legales y de privacidad siempre aplicables

Si tu WordPress recoge datos personales de clientes, usuarios registrados o simples visitantes que rellenan un formulario, estás sujeto al RGPD y a la Ley Orgánica de Protección de Datos, con independencia del tamaño de la empresa.

El RGPD exige aplicar medidas de seguridad adecuadas al riesgo, así que una brecha de seguridad es casi siempre también una brecha de protección de datos, con plazos y sanciones concretos.

La notificación a la AEPD debe hacerse en un máximo de 72 horas, con multas de hasta 10 millones de euros o el 2 % de la facturación para las infracciones graves (entre ellas, no notificar a tiempo) y de hasta 20 millones o el 4 % para las más graves.

Las sanciones a autónomos y pymes suelen moverse en varios miles de euros, lejos de los titulares millonarios pero suficientes para hacerte un agujero importante.

Qué hacer:

• Documenta cualquier incidente de seguridad, aunque decidas no notificarlo: el RGPD exige registrar internamente el análisis que llevó a esa decisión, precisamente para poder demostrarlo si la AEPD pregunta.
• Deja por escrito, en un contrato de encargo de tratamiento, quién es el responsable y quién el encargado cuando trabajas con una agencia o un servicio externo.
• Aplica minimización de datos: no guardes en formularios ni en la base de datos más datos personales de los estrictamente necesarios, porque cada campo de más es superficie expuesta de más el día que algo falle.
• Revisa avisos de cookies y política de privacidad con regularidad: están entre los motivos más frecuentes de sanción a pequeños negocios, haya habido o no una brecha técnica.
• Interioriza el plazo de las 72 horas antes de que ocurra un incidente, no durante: es la diferencia entre reaccionar con un protocolo decidido o improvisar bajo presión legal además de técnica.

Nada de esto sustituye el asesoramiento de un abogado especializado si la empresa maneja datos sensibles o de gran volumen.

Si ya te han entrado – Protocolo de las primeras horas

Aun con las cuatro puertas cerradas, un incidente sigue siendo posible, y cómo se reaccione en las primeras horas determina si se queda en un susto contenido o se convierte en una crisis larga.

Las señales de que algo va mal serían estas:

• Contenido, páginas o redirecciones que nadie de tu equipo ha creado.
• Picos de tráfico extraños, sobre todo dirigidos al login o al área de administración.
• Usuarios, plugins o temas nuevos que no reconoces.
• Entradas de registro anómalas: intentos de acceso repetidos, direcciones IP desconocidas, archivos modificados sin explicación.
• Avisos del navegador, de Google Search Console o de tu propio hosting marcando el sitio como inseguro o con malware.

Si aparece cualquiera de esas señales, el orden es importante:

1. Aísla el sitio: Activa el modo mantenimiento o restringe el acceso público mientras investigas, y si tu plugin de seguridad incluye un modo de emergencia con desafío para visitantes, es el momento de activarlo. El objetivo es frenar el daño sin perder lo que necesitarás analizar después.
2. Comunica con transparencia: en paralelo a la parte técnica, a quien pueda verse afectado. Tener el mensaje redactado de antemano evita improvisar bajo presión; en esta recopilación de recursos gratuitos tienes plantillas de comunicación de crisis, una lista de comprobaciones de acción inmediata y la calculadora de coste de caída con la que salen las cifras de la puerta 3 que te contaba antes.
3. Conserva una copia del estado comprometido antes de tocar nada, útil tanto para el análisis técnico como para una eventual denuncia o parte al seguro.
4. Restaura desde la copia de seguridad limpia más reciente, verificada y anterior al momento de la brecha.
5. Cambia todas las credenciales: contraseñas de todos los usuarios, no solo del administrador, además de las claves de la base de datos, las de API de servicios conectados y las de acceso al hosting y al registrador.
6. Ejecuta un escaneo completo de malware e integridad de archivos para confirmar que no queda ningún resto: puertas traseras, archivos añadidos o código inyectado que la restauración no haya eliminado.
7. Identifica y corrige la causa raíz (el plugin desactualizado, la contraseña débil, el permiso mal configurado) antes de volver a publicar, o el ataque se repetirá en cuanto el sitio vuelva a estar visible.
8. Evalúa la obligación de notificar a la AEPD y a los afectados si hay datos personales comprometidos, dentro del plazo de 72 horas.

Si la gestión del incidente supera la capacidad del equipo, o si el sitio maneja datos sensibles o pagos, merece la pena contar con apoyo externo especializado en recuperación de webs hackeadas, sea el mío, el de Sucuri como referencia internacional de pago o el equipo de seguridad de tu propio hosting si lo tiene, porque el tiempo que se ahorra evitando errores en caliente suele compensar el coste del servicio.

Con qué aplicarlo – Plugins y servicios recomendados

A lo largo de la guía he escrito varias veces «tu plugin de seguridad» sin concretar cuál, y toca hacerlo. Las opciones serias del mercado gratuito son Vigilante, Wordfence, Kadence Security y SG Security, que comparé función a función en este análisis de plugins de seguridad.

Vigilante es mío y lo uso en mis webs y en las de mis clientes, así que ya conoces el sesgo y puedes descontarlo, aunque cualquiera de los otros cumple razonablemente si se configura bien y se revisa a conciencia.

Además, te recomiendo llevar un registro de todo consentimiento que se haga en tu web, y como para esta necesidad no había nada suficientemente completo creé estos plugins, que como todos están disponibles gratis en WordPress.org o tu instalador de plugins:

• Registro de consentimientos de términos y condiciones: para llevar un registro legal de todos los consentimientos que pides en tu web, totalmente integrado con los ajustes de privacidad de WordPress.
• Cumplimiento del derecho de desistimiento de la UE: todo lo que necesitas, con tienda o sin ella, para registrar y cumplir con el derecho a desistimiento.

La otra decisión es quién aplica todo esto, si alguien de dentro o un servicio externo. Si decides delegarlo, sea en una agencia de confianza, en el plan de cuidado de algunos hostings gestionados o en un servicio de mantenimiento especializado como el que ofrezco yo mismo, exige que cubra como mínimo:

• La política de actualizaciones de la puerta 1, con prueba en staging y copia previa.
• Copias de seguridad verificadas, con restauración de prueba periódica y almacenadas fuera del servidor.
• Monitorización de disponibilidad e integridad con avisos, no solo un informe mensual.
• Revisión periódica de accesos, usuarios y extensiones instaladas.
• Protocolo de incidentes por escrito, con tiempos de respuesta comprometidos.

Con esa lista delante puedes evaluar cualquier presupuesto, incluido el mío. Un servicio que no restaura copias de prueba ni revisa accesos no está manteniendo tu web por mucho que actualice plugins.

Plan de arranque – Por dónde empezar

Si no tienes ninguna pieza de esta guía montada todavía, no intentes cerrarlo todo el mismo día. Este orden da más protección por minuto invertido:

1. Activa 2FA en WordPress para administradores y editores, y en la cuenta del registrador del dominio.
2. Fuerza contraseñas largas con caducidad, elimina usuarios del tipo admin o test, y pon en marcha el gestor de contraseñas de equipo.
3. Cierra la enumeración de usuarios, cambia la URL de acceso y desactiva XML-RPC si no lo usas.
4. Activa cortafuegos y escáner de integridad, aunque sea con la configuración por defecto del primer día.
5. Audita plugins y temas, desinstala lo que sobre y deja por escrito la política de actualizaciones.
6. Fuerza HTTPS en todo el sitio, revisa permisos de archivo y publica un security.txt.
7. Restaura un backup de prueba y saca las copias del servidor.
8. Publica DMARC en modo observación y comprueba tu SPF.
9. Verifica que tu hosting cumple los mínimos de la puerta 3 y activa la monitorización externa.
10. Documenta el protocolo de brechas (con las 72 horas de la AEPD dentro), prepara la plantilla de comunicación y forma al equipo en lo básico.

Y una advertencia final, nada de esta lista es tarea para realizar una sola vez. Agenda las revisiones (trimestral para accesos y extensiones, semestral para restaurar un backup de prueba) y trata la seguridad como lo que es, mantenimiento continuo y no un proyecto con fecha de fin.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!