Odio WordPress. Y no lo digo como alguien que no lo conoce, lo digo como alguien que lleva más de 20 años en seguridad informática y que tiene que lidiar con él prácticamente todas las semanas.

El 40% de la web tiene un problema

WordPress alimenta el 40% de internet. Eso significa que el 40% de internet comparte la misma superficie de ataque, los mismos plugins con vulnerabilidades, la misma estructura predecible y el mismo wp-admin esperando a que alguien lo encuentre.

La mayoría de mis clientes usan WordPress para lo mismo: una web escaparate. Cuatro páginas, un formulario de contacto y un par de fotos. Nada que justifique tener PHP ejecutándose en cada petición, una base de datos MySQL expuesta y 47 plugins de los cuales 12 llevan sin actualizarse desde 2021.

Y sin embargo, ahí están. Funcionando. Esperando.

La realidad que nadie quiere escuchar

┌─────────────────────────────────────────────────────────────────┐
│  SIN PROTECCIÓN                  │  CON SENTIDO COMÚN           │
├──────────────────────────────────┼──────────────────────────────┤
│  PHP ejecutándose en cada        │  Contenido estático.         │
│  petición.                       │  Cero ejecución de código.   │
│                                  │                              │
│  Base de datos expuesta a SQL    │  Sin base de datos en el     │
│  injection.                      │  frontend.                   │
│                                  │                              │
│  wp-admin accesible para         │  wp-admin invisible.         │
│  cualquiera.                     │  No existe para el mundo.    │
│                                  │                              │
│  Plugins introducen              │  El código de los plugins    │
│  vulnerabilidades nuevas.        │  nunca se ejecuta.           │
│                                  │                              │
│  Intentos de fuerza bruta        │  No hay página de login      │
│  contra el login.                │  que atacar.                 │
└──────────────────────────────────┴──────────────────────────────┘

Podemos instalar el mejor WAF del mercado, actualizar todo religiosamente, configurar permisos al milímetro. Pero mientras WordPress siga siendo WordPress, la superficie de ataque seguirá siendo enorme. No es un problema de configuración. Es un problema de arquitectura.

La pregunta que me cambió la perspectiva

Un día, revisando la enésima web de un cliente que había sido comprometida a través de un plugin de formularios, me hice una pregunta sencilla: ¿por qué estamos ejecutando código PHP para servir una página que no ha cambiado en 8 meses?

No tiene sentido. Es como dejar la puerta de casa abierta de par en par porque una vez al año necesitas que entre el técnico del gas.

FrontWall: mi respuesta al problema

Así nació FrontWall. No como un proyecto bonito ni como una startup. Como una herramienta que necesitaba y que no existía.

La idea es brutalmente simple:

FrontWall se coloca delante de tu WordPress
Rastrea y almacena todo el contenido como ficheros estáticos
Sirve esos ficheros a los visitantes a través de un servidor seguro
WordPress queda completamente oculto para internet

Los visitantes reciben páginas rápidas. Los atacantes no reciben nada. WordPress se convierte en invisible.

Internet → Reverse Proxy → FrontWall Shield → Caché Estática
                                    ↓ (solo POST, sanitizado)
                                 WordPress (oculto)

No solo caché estática

Porque servir ficheros estáticos no es suficiente. FrontWall incluye todo lo que he echado en falta durante años protegiendo estas webs:

WAF integrado que bloquea SQL injection, XSS, path traversal y las herramientas habituales de escaneo
Sanitización de POST en múltiples capas para los formularios de contacto que sí necesitan funcionar
Rate limiting por IP con token bucket y sharding para no morir bajo carga
Bloqueo geográfico para cortar de raíz el tráfico desde orígenes sospechosos
Security headers automáticos en cada respuesta: CSP, HSTS, X-Frame-Options
Modo bypass para cuando el cliente necesita actualizar contenido sin desplegar nada
Modo aprendizaje que detecta formularios y genera reglas automáticamente

Todo open source. Sin licencias, sin ataduras, sin "llámanos para el plan enterprise".

Rendimiento: cuando la seguridad y la velocidad van juntas

Una de las cosas de las que estoy más satisfecho es del rendimiento. Una petición a un fichero CSS cacheado que ya se ha servido antes tarda aproximadamente 5 microsegundos. Antes de las optimizaciones tardaba entre 350 y 1.400 microsegundos. Estamos hablando de una mejora de entre 70x y 280x.

"La mejor defensa contra un ataque a WordPress es que WordPress no esté ahí."

Para quién es esto

Si tienes un WordPress que es básicamente un escaparate, que cambias una vez al año y que sin embargo mantiene PHP, MySQL y 30 plugins funcionando las 24 horas del día para servir contenido que podría ser un fichero HTML plano... FrontWall es para ti.

No es una solución para todo. Si necesitas un e-commerce dinámico o un sistema de membresías complejo, WordPress seguirá siendo tu cruz. Pero para el 80% de los sitios WordPress que veo en mi día a día, esto es exactamente lo que necesitan: desaparecer de internet sin dejar de estar online.

El proyecto está en GitHub. Si lo pruebas y encuentras algo que mejorar, las pull requests están abiertas.

[PROJECT: github.com/acalatrava/FrontWall]
[LICENSE: MIT]
[EOF]