El síntoma
Estás trabajando en el backoffice de PrestaShop y, al usar funciones que realizan peticiones AJAX en segundo plano (buscador de productos relacionados, autocompletado de clientes, asistentes de combinaciones, gestores de stock, módulos que llaman a un endpoint propio…), parte de la interfaz no responde. Si abres la consola del navegador, ves peticiones que devuelven un error HTTP 403 (Forbidden).
Lo curioso es que el resto del backoffice funciona, el front office responde con normalidad y tu sesión no ha caducado. Solo esas peticiones concretas son las que reciben el 403.
Por qué ocurre
En los servidores de TropicalServer hay un cortafuegos de aplicación (ModSecurity) que inspecciona en tiempo real el contenido de cada petición HTTP. Su trabajo es bloquear ataques conocidos contra PrestaShop, WordPress, Joomla y otros CMS (inyecciones SQL, intentos de subida de archivos, patrones de exploit, etc.).
Algunas peticiones AJAX legítimas del backoffice de PrestaShop —especialmente las que envían parámetros con caracteres especiales, búsquedas, IDs múltiples o cuerpos JSON— pueden coincidir con las firmas genéricas que ModSecurity usa para detectar ataques. Cuando eso ocurre, la petición se bloquea con un 403 antes de llegar al PHP de PrestaShop, lo que rompe la funcionalidad sin dejar rastro en los logs de la propia tienda.
Cómo diagnosticarlo
Abre la consola del navegador en el backoffice (F12 → pestaña Red) y reproduce la acción que falla.
Si la petición devuelve HTTP 403 con un cuerpo muy breve o casi vacío, y el resto del backoffice carga bien, es un fuerte indicio de que ModSecurity la está bloqueando.
Confirma que el error no sucede en todas las acciones, sino solo en las AJAX concretas. Si no carga nada del backoffice o ves 500, el problema es otro distinto.
Solución
Esta es una intervención que debe realizar el equipo de soporte de TropicalServer: no hay que tocar las reglas globales del firewall ni desactivar ModSecurity completo, porque dejarías la tienda expuesta. Lo correcto es añadir excepciones específicas para las reglas que estén bloqueando esas peticiones, manteniendo el resto del cortafuegos activo.
Qué necesitamos para resolverlo
Al abrir el ticket, indícanos:
El dominio de la tienda y la versión de PrestaShop.
La URL del backoffice (especialmente si la has movido a una ruta personalizada) y datos de acceso si quieres que reproduzcamos el error.
El paso a paso exacto para llegar al punto donde se produce el 403 (por ejemplo: "edito un producto, voy a la pestaña Asociaciones, escribo en el buscador de productos relacionados").
Una captura del error 403 en la pestaña Red del navegador, si la tienes.
Con esa información buscamos en los logs del cortafuegos qué regla concreta de ModSecurity coincide con la petición, comprobamos que la URL y la acción son seguras y añadimos la excepción correspondiente solo para tu cuenta y para esa ruta concreta. Las reglas se mantienen aplicadas y la tienda queda igual de protegida.
Lo que conviene revisar antes de pedir excepciones
Antes de pedir una excepción, descarta lo siguiente:
Que no sea un módulo de terceros desactualizado el que está enviando parámetros mal formados. Si actualizar el módulo resuelve el 403, mejor que añadir excepciones.
Que la URL no contenga caracteres extraños inyectados por un plugin de SEO o por una redirección agresiva.
Que la cookie de sesión del administrador no esté caducada (esto suele dar 401/302, no 403, pero conviene refrescar la sesión por si acaso).
Una vez aplicada la excepción, la acción del backoffice vuelve a funcionar de inmediato sin necesidad de borrar caché ni reiniciar nada en la tienda.