El 10 de octubre de 2026 hicimos una auditoría de seguridad del servidor donde se aloja la tienda velasdeolor.es, un servidor cloud de Hostinger. No fue una prueba de intrusión, sino una revisión ordenada de la configuración: qué envía el servidor, qué se puede abrir desde fuera, qué puede ejecutar PHP y quién avisa cuando algo falla. Contamos lo que encontramos y cómo lo resolvimos, sin entrar en detalles que puedan ayudar a un atacante.
Si ya hay módulo de seguridad y firewall, ¿para qué una auditoría?
La tienda ya tenía un módulo de seguridad con escaneos, filtro por países en la CDN, bloqueo de bots y copias de seguridad. Pero las capas de seguridad tienen huecos entre ellas, y el primer hallazgo de la auditoría es un buen ejemplo.
1. Cabeceras de seguridad, también en las páginas en caché
Las cabeceras de seguridad son instrucciones que el servidor da al navegador: usar siempre HTTPS (HSTS), no adivinar el tipo de los archivos (X-Content-Type-Options) y no dejar que otra web muestre la tienda dentro de un marco (X-Frame-Options), una técnica que se usa para engañar al usuario y que haga clic donde no quiere.
La tienda las enviaba… a veces. Las ponía el módulo de seguridad desde PHP, pero la portada, las categorías y las fichas de producto, que son la mayoría de las visitas, se sirven desde la caché de páginas sin ejecutar PHP. Resultado: justo las páginas más vistas llegaban sin cabeceras. La solución fue declararlas en el .htaccess, para que las envíe el propio servidor en todas las respuestas. HSTS lo activamos para un año y sin incluir los subdominios, porque no todos tienen las mismas necesidades.
El siguiente paso sería una política de seguridad de contenidos (CSP), pero en una tienda PrestaShop con muchos módulos que insertan scripts hay que prepararla con mucho cuidado para no romper nada.
2. Registros y archivos que no deberían verse desde fuera
- Registros de errores de PHP y otros archivos .log dentro de carpetas públicas. Revelan rutas, versiones y, a veces, datos. Ahora el servidor niega el acceso a ellos en cualquier carpeta, y se revisan desde el administrador de archivos del panel de Hostinger.
- Volcados de base de datos y archivos de desarrollo (dependencias de Composer o npm, configuraciones de herramientas) que venían con algunos módulos. Mismo tratamiento.
- Restos olvidados: una copia antigua de un módulo en una carpeta temporal, con un script que se podía lanzar desde fuera, un script antiguo de un servicio antispam y carpetas que deja macOS al comprimir. Fuera, o cerradas a la web.
Un apunte técnico para quien trabaje con Hostinger: el servidor web es LiteSpeed, que interpreta el .htaccess como Apache pero no siempre igual. En nuestras pruebas, la directiva Require ip no restringía el acceso por IP como esperábamos, mientras que Require all denied sí funcionaba. Para filtrar por IP usamos la sintaxis antigua (Order, Deny, Allow) o una regla de reescritura con la dirección remota. La moraleja: prueba cada regla desde fuera, no te fíes de que está escrita.
3. Funciones de PHP que la tienda no necesita
PHP permite desactivar funciones peligrosas. La tienda ya tenía desactivadas las que ejecutan comandos del sistema más conocidas, y tras una prueba controlada añadimos otras dos de la misma familia que seguían disponibles. Si alguien consiguiera subir un archivo PHP malicioso, lo tendría bastante más difícil para ejecutar órdenes en el servidor.
Tiene un coste: algunas herramientas legítimas, como el asistente de actualización de PrestaShop por línea de comandos, usan esas funciones. Lo contamos en cómo actualizamos PrestaShop a 8.2.8: se puede trabajar sin ellas o habilitarlas solo durante el tiempo justo.
4. Tareas programadas que avisan cuando fallan
- El escaneo de malware, la limpieza de carritos antiguos y la vigilancia del módulo de seguridad se lanzan desde un servicio externo de tareas programadas que avisa si una tarea falla y guarda el historial.
- Quitamos un aviso que saltaba por cambios de IP del servidor: con la CDN delante, lo que veía eran IP de la propia CDN. Las falsas alarmas son peligrosas, porque acostumbran a ignorar los avisos.
- Después de cada actualización hay que tomar una nueva referencia de archivos: si no, el módulo avisará de miles de cambios legítimos y esconderá el que importa.
Checklist para revisar tu servidor
- Comprueba las cabeceras de seguridad en una página servida desde la caché y en otra que no lo esté.
- Busca en las carpetas públicas archivos .log, .sql, error_log, copias en .zip y carpetas tipo «old», «backup» o «tmp».
- Borra o cierra a la web lo que no se use.
- Desactiva las funciones de PHP que tu web no necesite.
- Programa los escaneos con un sistema que te avise si fallan.
- Haz una copia del .htaccess antes de tocarlo y prueba cada regla desde fuera.
Si quieres que revisemos la seguridad de tu servidor o de tu tienda online, contacta con nosotros. Y para la parte de la propia tienda, tienes nuestra checklist de seguridad para PrestaShop y el artículo sobre la seguridad del backoffice.
