Por qué reforzar el acceso al backoffice
Cuando una tienda PrestaShop no puede actualizarse de forma inmediata (versiones antiguas tipo 1.7.x con módulos a medida que romperían la migración), una medida temporal muy eficaz es restringir el acceso al backoffice a una IP concreta y, además, renombrar la carpeta del propio backoffice. Esto no soluciona vulnerabilidades de fondo (que siguen requiriendo actualización de la versión y de los módulos), pero reduce drásticamente la superficie de ataque frente a intentos automatizados desde Internet.
Esta guía aplica a tiendas alojadas en hosting compartido o Cloud con cPanel en Tropical Server.
Paso 1: averigua la IP fija desde la que vas a trabajar
El método solo es útil si conoces y controlas la IP pública desde la que tú (o tu equipo) os conectaréis al backoffice. Puedes consultarla en:
Si tu IP cambia con frecuencia (conexión doméstica dinámica), valora primero contratar IP fija con tu operador o usar una VPN corporativa con IP de salida estable. De lo contrario te quedarás tú mismo fuera del backoffice cada vez que cambie la IP.
Paso 2: renombra la carpeta del backoffice
Las instalaciones de PrestaShop crean una carpeta de administración con un nombre tipo admin123 o similar. Ese nombre se conoce y se rastrea constantemente desde la red. El primer paso es darle un nombre que no sea predecible:
Entra en cPanel > Administrador de archivos.
Sitúate en public_html.
Localiza la carpeta del backoffice (por ejemplo admin123) y renómbrala a algo único, combinando letras y números, por ejemplo admin-x82fhd.
Accede una vez a https://tudominio.com/nuevo-nombre para comprobar que entra correctamente. Si todo va bien, el backoffice habrá quedado en la nueva ruta automáticamente.
Renombrar esta carpeta no rompe los módulos ni el frontoffice de PrestaShop: el frontoffice no depende de su nombre y los módulos legítimos no acceden a esa ruta directamente.
Paso 3: añade una regla en el .htaccess del backoffice
Dentro de la nueva carpeta del backoffice (no en el .htaccess raíz de public_html) edita o crea un archivo .htaccess con este contenido:
<Limit GET POST>
order deny,allow
deny from all
allow from TU_IP_PUBLICA
</Limit>
Sustituye TU_IP_PUBLICA por la IP fija que comprobaste en el paso 1. Si necesitas dar acceso a varias IPs, añade una línea allow from adicional por cada IP. Solo se permitirá el acceso al backoffice desde esas IPs; el resto del mundo verá un 403 Forbidden al intentar entrar a esa carpeta.
Paso 4: replica el mismo patrón en carpetas sensibles que no deban ser accesibles desde fuera
Si tienes módulos a medida cuyas URLs no las llama nadie desde Internet (porque solo las consume tu propio backoffice o procesos internos), puedes añadir un .htaccess equivalente dentro de esas subcarpetas. Importante: no aplicar este bloqueo a /modules/ ni a /themes/ completos, ya que muchos módulos cargan recursos (CSS, JS, imágenes) que sí deben ser accesibles públicamente desde el frontoffice. Restríngelo solo a directorios concretos de los que estés seguro.
Qué hace y qué NO hace esta protección
Lo que sí consigues:
Bloquear cualquier intento de login al backoffice desde IPs no autorizadas.
Cortar sesiones robadas o tokens reutilizados desde otra IP.
Frenar bots y scanners que rastrean nombres típicos de carpetas administrativas de PrestaShop.
Lo que no consigues:
Cerrar vulnerabilidades de versiones antiguas de PrestaShop o de módulos vulnerables: estas siguen permitiendo que un atacante cree usuarios ficticios o ejecute código sin pasar por el login.
Proteger frente a inyecciones en formularios públicos del frontoffice (suscripción, carrito, contacto, etc.).
Por eso es una medida temporal mientras se planifica la actualización a una versión soportada (PrestaShop 8.2.x o superior, idealmente 9.x). En paralelo, conviene revisar JetBackup para descartar intrusiones y migrar la tienda con la herramienta MigrationPro Ultimate a un subdominio de pruebas antes de mover la nueva versión a producción.
Errores frecuentes al aplicar la regla
Editar el .htaccess raíz en lugar del .htaccess de la carpeta del backoffice: bloquea TODO el sitio, no solo el panel.
Olvidar añadir la propia IP en allow from: te dejarás a ti mismo fuera. En ese caso, accede por Administrador de archivos de cPanel y corrige el archivo.
Aplicar la restricción dentro de /modules/ entero: rompe vistas del frontoffice que cargan recursos desde módulos.
No renombrar la carpeta del backoffice: los bots siguen golpeando /admin123 aunque el contenido esté bloqueado por IP, lo que genera ruido y carga innecesaria.