En resumen: un sitio web estático se compone de archivos HTML, CSS e imágenes terminados que el servidor web solo sirve. Como en el servidor no se ejecutan ni PHP ni base de datos, vulnerabilidades como PHP2Shell, la inyección SQL o las webshells inyectadas dejan de ser en gran medida un riesgo. Para la seguridad de un sitio web estático cuentan en cambio otras cosas: accesos protegidos al alojamiento, al dominio y a las herramientas de compilación, dependencias mantenidas y servicios de terceros elegidos con cuidado. Resulta adecuado sobre todo para sitios web que rara vez cambian y no necesitan cuentas de cliente.
Por qué la pregunta se plantea justo ahora
PHP2Shell ha mostrado a muchas empresas cuánto depende de un único componente. Un sitio web corporativo de diez páginas que se actualiza una vez por trimestre funcionaba con el mismo PHP que una gran tienda online y estaba así expuesto a la misma vulnerabilidad crítica. Según informaciones de los medios, incluso autoridades y municipios desconectaron sitios web de forma preventiva.
Surge entonces la pregunta: ¿necesitamos siquiera PHP en el servidor para nuestro sitio web? En muchas pequeñas y medianas empresas, la respuesta honesta es: para servirlo, a menudo no. PHP genera la página de nuevo en cada acceso, aunque el contenido no haya cambiado en semanas. Cómo funciona esto técnicamente lo describe Cómo genera PHP una página web. Qué significa la vulnerabilidad en sí lo explica ¿Qué es PHP2Shell?.
Cómo funciona un sitio web estático
En un sitio web estático, la página no se genera al visitarla, sino antes. Un generador de páginas estáticas, como Hugo, Jekyll o Eleventy, toma textos, imágenes y plantillas y construye con ellos archivos terminados. Estos archivos se cargan en un servidor web sencillo o en una red de entrega de contenidos, es decir, una red de distribución, o CDN.
Para los redactores puede haber delante una herramienta de edición que recibe los cambios y desencadena la reconstrucción. En parte se utiliza para ello un llamado CMS headless, que solo gestiona contenidos y no tiene por qué ser accesible públicamente. El visitante no ve nada de esto; solo recibe los archivos terminados.
Sitio web estático y seguridad, comparados
| Criterio | CMS dinámico en PHP | Sitio web estático |
|---|---|---|
| Lógica de programa en el servidor público | Sí, en cada acceso | No |
| Riesgo por vulnerabilidades en el intérprete de PHP | Sí, como en PHP2Shell | Desaparece en el servidor de entrega |
| Base de datos conectada públicamente | Sí | No |
| Puertas de entrada típicas | Plugins, inicio de sesión de administración, subidas, servidor | Accesos al alojamiento, al dominio, al sistema de compilación, servicios de terceros |
| Formularios, búsqueda, cuenta de cliente | Incorporados | Solo mediante servicios externos o funciones separadas |
| Esfuerzo de mantenimiento para redactores | Bajo, interfaz habitual | Depende de la herramienta editorial |
| Mantenimiento | Actualizaciones periódicas de CMS, plugins y PHP | Actualizaciones de las herramientas de compilación y las dependencias |
| Idoneidad | Tiendas, portales, muchos redactores, cambios frecuentes | Sitios corporativos, landing pages, documentación |
La tabla muestra: la superficie de ataque se desplaza, no desaparece. En lugar de un servidor PHP accesible públicamente, debe proteger la cuenta en el proveedor de alojamiento, el dominio, el pipeline de compilación y, en su caso, la herramienta editorial.
Qué riesgos permanecen en los sitios web estáticos
Primero, los accesos. Quien se hace con la cuenta de alojamiento, el acceso al dominio o el repositorio de código puede modificar el sitio web, sin PHP alguno. La autenticación de dos factores y las cuentas personales son por ello obligatorias.
Segundo, las dependencias. Los generadores y las plantillas traen a menudo muchos paquetes, por ejemplo de npm. Estos deben mantenerse actualizados, porque una dependencia comprometida puede escribir código malicioso en los archivos terminados durante la compilación. Cómo organizarlo lo describe Mantener las dependencias actualizadas.
Tercero, los servicios de terceros. Los servicios de formularios, las funciones de búsqueda, las herramientas de análisis y los scripts integrados se ejecutan en el navegador de los visitantes o en servidores ajenos. Cada uno de estos servicios es una relación de confianza, también desde el punto de vista de la protección de datos.
Cuarto, el lado del navegador. También una página estática debería establecer cabeceras de seguridad, por ejemplo una Content-Security-Policy que determine qué scripts pueden cargarse. Los fundamentos están en Cabeceras de seguridad para sitios web.
Antes de cambiar, compruebe qué funciones usa realmente su sitio web. A menudo son menos de las que se piensa: páginas, imágenes, un formulario de contacto. Entonces el camino hacia el sitio web estático es más corto de lo que parece al principio.
Para quién compensa el cambio y para quién no
Un sitio web estático es muy adecuado para páginas corporativas de extensión manejable, landing pages para campañas, documentación de productos y páginas de empleo. El cambio compensa especialmente si el sitio web actual funciona con una versión antigua de PHP y de todos modos tocaría actualizar.
Es menos adecuado para tiendas online, portales de clientes, sistemas de reservas y sitios web con muchos redactores que publican a diario. Aquí sigue teniendo sentido un sistema dinámico. Una forma mixta puede ayudar: la tienda sigue siendo dinámica y se refuerza bien, mientras que las guías y las páginas corporativas se sirven de forma estática.
Una ventaja a menudo subestimada se muestra en caso de emergencia. Como los archivos terminados pueden reconstruirse en cualquier momento a partir de plantillas y contenidos, un sitio web manipulado puede restablecerse con rapidez a un estado conocido y limpio. El requisito es que los contenidos y las plantillas estén en un repositorio protegido, que los cambios se registren de forma trazable y que nadie edite los archivos directamente en el servidor.
Para el cambio no necesita forzosamente un proveedor de seguridad; puede encargarse una agencia o un desarrollador. Si el sitio web anterior estuvo comprometido, sin embargo, los contenidos deberían revisarse antes de trasladarlos. De ello trata ¿Cambiar de CMS tras el hackeo?.
¿Cómo ayuda PHP SOS en concreto?
- Comprobamos qué funciones necesita realmente su sitio web y decimos abiertamente si una solución estática es adecuada.
- En un cambio protegemos los accesos al alojamiento, al dominio y al sistema de compilación con autenticación de dos factores y cuentas personales.
- Revisamos los servicios de terceros y establecemos cabeceras de seguridad, para que el nuevo sitio web esté bien protegido también en el navegador.
- Para los sistemas PHP que se mantengan asumimos actualizaciones y vigilancia en el contrato de mantenimiento de seguridad.
Conclusión
Un sitio web estático no es una panacea, pero para muchas páginas corporativas es la forma más sencilla de librarse de toda una clase de riesgos. Donde no se ejecuta PHP, PHP2Shell no puede hacer nada. Pero la seguridad ganada solo se mantiene si los accesos, las dependencias y los servicios de terceros se toman tan en serio como antes el servidor.
Preguntas frecuentes
¿Se puede hackear igualmente un sitio web estático?
Sí. Desaparece la lógica de programa del lado del servidor y, con ella, una gran clase de ataques. Pero siguen siendo atacables los accesos al alojamiento, al dominio y al sistema de compilación, los servicios de terceros integrados y las herramientas con las que se genera la página.
¿Puede un sitio web estático tener formularios de contacto?
Sí, mediante un servicio de formularios externo o una pequeña función operada por separado. Entonces el tratamiento de los datos corre a cargo de ese servicio. Aclare la protección de datos y el encargo de tratamiento antes de integrarlo.
¿Pueden los redactores mantener por sí mismos un sitio web estático?
Con una herramienta editorial adecuada, sí. Muchas soluciones ofrecen una interfaz de edición a partir de la cual la página se genera de nuevo. Para equipos que cambian muchos contenidos cada día, un CMS clásico suele ser más cómodo.
¿Compensa el cambio para una tienda online?
Normalmente no por completo. El carrito, la cuenta de cliente y el pago necesitan lógica del lado del servidor. Es posible servir de forma estática partes como guías o páginas corporativas y operar la tienda por separado.