Cómo se filtra la URL del back-office y cómo cerrarle el paso

Varias veces en 2026 salió en el grupo la misma pregunta: si la carpeta de administración tiene un nombre aleatorio, ¿cómo llega un bot directamente a ella? En julio, Gustavo pasó los registros de una tienda a la IA y el resultado fue claro: un bot fue derecho a la URL del back-office, intentó iniciar sesión y no pudo. Respuesta corta: la dirección se escapa de la propia tienda, sobre todo por la cabecera Referer y por scripts de terceros cargados en el back-office, y hay que cerrar las dos vías.

Por dónde se escapa

• La cabecera Referer. Cuando pulsas un enlace del back-office que lleva a otra web, o cuando el back-office carga algo de fuera, el navegador puede decirle a ese destino desde qué página vienes. Los navegadores actuales, por defecto, solo envían el dominio a otras webs; la ruta completa, con tu carpeta de administración, se escapa cuando la página, un módulo o el servidor relajan esa política, o con navegadores antiguos.
• Analítica y scripts de terceros dentro del back-office. Un módulo que mete un script de seguimiento o un chat también en la administración envía la dirección de la página que está viendo. Ahí no hace falta ningún Referer.
• Personas y equipos. Capturas, correos con la URL, colaboradores que ya no están o un equipo con un programa que roba el historial del navegador.

La política de Referer

En octubre Gustavo publicó un módulo que añade la cabecera Referrer-Policy (por defecto, no-referrer en el back-office) para que la dirección del panel no salga hacia la analítica ni hacia otras webs, «mientras lo arreglan en versiones próximas». Si prefieres hacerlo en el servidor, en Apache basta con esto en la configuración de la carpeta de administración:

<IfModule mod_headers.c>
    Header always set Referrer-Policy "same-origin"
</IfModule>

Con same-origin, el navegador solo envía el Referer dentro de tu propio dominio; a cualquier otra web no le dice de dónde vienes.

En el núcleo, PrestaShop prepara cabeceras de seguridad nativas, entre ellas Referrer-Policy, en la PR 43192, todavía abierta y prevista para la 9.3.

Y lo otro: no cargues scripts de terceros en el back-office. Revisa qué módulos enganchan código en los hooks de administración y quita lo que no haga falta.

Si ya tienen la URL: que no puedan instalar módulos

En octubre Gustavo avisó de un fallo serio en PrestaShop 9.1 (y quizá en 8.2): con acceso al back-office, un script en Python podía instalar módulos sin dejar rastro en los registros. Un módulo instalado es, en la práctica, código del atacante dentro de tu servidor. No hemos encontrado un aviso oficial que lo confirme: sigue los avisos de seguridad de PrestaShop.

Mientras tanto, la idea de Gustavo fue cortar en el servidor las subidas de módulos que no vengan de un navegador «marcado»: el .htaccess rechaza la petición de importar un módulo si no lleva una cookie secreta que solo tiene el administrador. Si lo copias, inventa tu propio nombre y valor de cookie y no los publiques, y comprueba en una copia que la ruta de subida coincide con la de tu versión. Bloquear el agente python-requests también ayuda, pero cualquiera puede cambiar su agente: no lo cuentes como protección.

Lo que conviene tener ya

1. Cambia el nombre de la carpeta de administración si sospechas que se ha filtrado.
2. Limita el back-office por IP si el equipo trabaja desde direcciones fijas.
3. Un aviso al instalar un módulo o crear un empleado, para enterarte en minutos y no en semanas.
4. Acceso sin contraseña robable. Gustavo ha publicado Ecom Passkey, que abre el back-office con la huella, la cara o el PIN del equipo o del móvil; una web falsa no puede robar ese acceso porque la passkey solo funciona en el dominio de tu tienda. Necesita PrestaShop 8.2 o superior y back-office por HTTPS. Lo compara con el doble factor en este artículo.

Para el aviso inmediato, en Rekire usamos el módulo de alertas de seguridad por Telegram.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación