Seguridad en PrestaShop: refuerzo, acceso y recuperación

Qué haríamos

Primero determinaríamos si estás previniendo un problema o respondiendo a indicios de una intrusión. Para el refuerzo habitual, inventaría lo que ya usas antes de elegir herramientas: alojamiento, PrestaShop y PHP, módulos, integraciones, personalizaciones del tema, datos guardados, mercados y personas que necesitan acceso. Una integración de almacén, un equipo de soporte que viaja y un formulario de pago integrado imponen requisitos distintos. Conserva los controles que ya funcionan y resuelve las carencias que puedas demostrar.

Si tu tienda no puede usar software mantenido, compara actualizar la instalación existente con una instalación de destino limpia y una migración controlada de datos. La vía adecuada depende de tu código personalizado, los módulos sustitutos, el tema, las integraciones y la calidad de datos. Reforzar una tienda sin soporte contiene riesgos concretos mientras avanza ese trabajo; no restablece el mantenimiento del proyecto original. Si sospechas una intrusión, conserva las pruebas y sigue la sección de respuesta a incidentes antes de tratar la tienda como una copia inicial segura.

Para cambios planificados, usa una copia de pruebas protegida, ensaya los recorridos comerciales afectados, registra cómo revertir el cambio y acuerda un cambio en producción con un responsable que supervise el resultado. Una migración de plataforma o base de datos también necesita un plan para los pedidos y otras escrituras recibidas mientras se prepara la copia.

Si quieres una evaluación independiente, el PrestaShop Security Audit & Hardening Report revisa la exposición acordada y proporciona un plan priorizado; la implementación y la reparación de incidentes se delimitan aparte.

Empieza por la prevención, la detección y la recuperación

Protege la tienda en varios niveles: software con soporte, accesos individuales, permisos restringidos, reglas del servidor, filtrado de tráfico, supervisión y copias recuperables. HTTPS protege los datos en tránsito. Una copia de seguridad te ayuda a recuperarte. Ninguno sustituye los parches.

Los riesgos incluyen inyección SQL en el núcleo o módulos, credenciales de empleados robadas, subidas vulnerables, paquetes maliciosos y copias o configuraciones expuestas. El proceso de compra puede seguir funcionando mientras JavaScript inyectado roba datos. Una tienda pequeña también necesita estos controles.

1. Registra las versiones exactas de PrestaShop, PHP, base de datos, tema y módulos.
2. Haz copia de los archivos y la base de datos, y demuestra que puedes restaurarlos en una copia aislada.
3. Aplica las correcciones de seguridad en pruebas y comprueba el proceso de compra antes de producción.
4. Da a cada empleado una cuenta única, una contraseña sólida y un segundo factor.
5. Revisa las rutas con escritura, los endpoints públicos y las alertas de supervisión.

Asigna un responsable y una fecha de revisión a cada control. Revisa los accesos tras cambios de personal y repite periódicamente la revisión general. Protege el entorno de pruebas con autenticación y desactiva allí los pagos reales, los emails a clientes y las integraciones de producción.

Mantén PrestaShop y PHP con soporte

La compatibilidad y el mantenimiento de seguridad son cuestiones distintas. PrestaShop 8.0 a 8.2 solo admite PHP hasta 8.1. PrestaShop 9.0 admite PHP de 8.1 a 8.4; 9.1 admite de 8.1 a 8.5. La versión 9.2 también admite PHP de 8.1 a 8.5. Comprueba la versión exacta y todos los módulos antes de cambiar PHP. Consulta la tabla de compatibilidad y los requisitos de 9.2.

A fecha de 26 de octubre de 2026, PHP 8.1 ya ha llegado al final de su vida útil. Su soporte de seguridad oficial terminó el 31 de diciembre de 2025. PHP 7.4 terminó su soporte el 28 de noviembre de 2022. Comprueba el ciclo de vida de PHP además de la compatibilidad de la plataforma. Planifica una actualización de plataforma si tu tienda no puede usar un entorno mantenido; valida explícitamente cualquier acuerdo de soporte ampliado.

El mantenimiento oficial ordinario de PrestaShop 1.7 terminó al publicarse 9.0. Una corrección urgente excepcional posterior no significa que la rama siga mantenida. PrestaShop 1.6 también está fuera del mantenimiento oficial. Sigue la política de mantenimiento y planifica tu migración.

Aplica parches también al sistema operativo, la base de datos, el servidor web y los módulos. Mantén un inventario de módulos y suscríbete a los avisos de proveedores y a los avisos de seguridad de Friends of Presta. Un número de versión por sí solo no demuestra que un exploit concreto sea aplicable.

Usa la lista de comprobación de migración para planificar los cambios entre versiones de PHP y PrestaShop.

Ensaya el cambio y la vuelta atrás

Por ejemplo, endurecer las reglas de subida puede proteger los adjuntos de clientes y a la vez romper un módulo que los procesa mediante un punto de acceso antiguo. Registra primero las rutas reales que usa ese módulo. Ensaya por separado las subidas normales y los nombres de archivos ejecutables bloqueados para que una imagen de producto correcta no oculte un flujo de adjuntos roto.

1. Guarda la configuración actual, las rutas afectadas, las credenciales de integración y un punto de restauración correspondiente de archivos y base de datos. Registra el comportamiento esperado antes de cambiar nada.
2. Crea la copia protegida con los mismos gestores de servidor, reglas de proxy, módulos y tema pertinentes. Restringe el acceso a los datos de clientes copiados y sustituye los destinos de producción por servicios de prueba o simulaciones controladas.
3. Aplica un cambio lógico cada vez. Cambiar simultáneamente PHP, un módulo y el cortafuegos dificulta atribuir un fallo.
4. Prueba acciones permitidas y denegadas: acceso y recuperación de empleados, intentos de acceso fuera del rol, navegación del catálogo, subidas, compra, notificaciones de pago, reembolsos, tareas programadas y sincronización de socios según corresponda.
5. Ensaya la reversión. Restaurar un archivo de configuración, revertir código desplegado y restaurar una base de datos tienen consecuencias distintas; identifica qué requiere el cambio y quién puede hacerlo.
6. Acuerda la ventana del cambio, las comprobaciones para seguir o detenerse y el criterio de reversión. Si se trasladan datos entre instalaciones, define cómo se pausan o concilian las escrituras y cómo se gestionan las notificaciones de pago entrantes.
7. Tras el cambio, comprueba la tramitación real de pedidos y el canal de alertas. Conserva los resultados de pruebas, los ajustes cambiados y las instrucciones de mantenimiento para la siguiente versión.

Restaurar una base de datos puede borrar pedidos realizados después del punto de restauración. Para revertir una migración, acuerda cómo conciliar esos pedidos y los pagos del proveedor antes de volver atrás. Mantén protegido el entorno anterior mientras se conserve para recuperación.

Para una tienda antigua que necesita una plataforma mantenida, el PrestaShop Upgrade Service: Any Version to PrestaShop 9 evalúa la versión existente, PHP, el alojamiento, el tema y los módulos antes de ofrecer un presupuesto escrito y trabaja después en un entorno de pruebas antes del cambio en producción.

Localiza o cambia la URL de tu back office

El back office reside en un directorio físico bajo la raíz de la tienda. Si esta está instalada en /shop/, incluye esa ruta base antes del directorio de administración. Usa SFTP, el gestor de archivos del alojamiento o SSH para localizarlo.

Busca la raíz de la tienda que contiene classes/, modules/ y themes/. Los nombres de directorio candidatos suelen empezar por admin, pero un directorio renombrado puede tener otro nombre. Inspecciona su index.php para localizar el arranque de administración y la definición de _PS_ADMIN_DIR_. No es necesario un subdirectorio controllers/ dentro de él.

El archivo estándar app/config/parameters.php no almacena el nombre de la carpeta de administración. Mantén privado el nombre aleatorio existente o renombra la carpeta real durante una ventana de acceso coordinada. No es necesario cambiar ninguna configuración estándar de la base de datos para que coincida.

1. Mantén disponible un acceso SFTP o de alojamiento operativo.
2. Pide a tus compañeros que cierren sesión y renombra el directorio.
3. Actualiza las referencias personalizadas de proxy, cortafuegos, tareas programadas o módulos a la ruta anterior.
4. Abre la nueva URL HTTPS y prueba el inicio de sesión.
5. Actualiza los marcadores y las entradas del gestor de contraseñas. Comprueba que la ruta anterior ya no abre el back office.

Un enlace simbólico desde el nombre anterior mantiene accesible ese punto de entrada. Una ruta privada reduce los escaneos casuales, pero sigue necesitando autenticación sólida y restricciones de acceso.

Contraseñas, autenticación de dos factores y sesiones de empleados

En versiones modernas, abre Parámetros avanzados > Equipo > Empleados, Perfiles y Permisos. En PrestaShop 1.6, estas páginas están en Administración. Da a cada persona una cuenta de empleado identificada. Evita compartir el acceso del propietario.

Usa contraseñas largas y únicas generadas con un gestor de contraseñas. Una contraseña aleatoria de 16 caracteres o más es una política práctica. Cambia enseguida las contraseñas comprometidas o reutilizadas. La rotación forzada rutinaria no sustituye la longitud y la exclusividad. El núcleo moderno usa su servicio Crypto Hashing con bcrypt y verificación de hashes antiguos; no restablezcas contraseñas con MD5 en bruto.

El TOTP del back office requiere un módulo compatible o una capa externa de identidad y acceso. El núcleo no ofrece el interruptor universal TOTP descrito en muchos tutoriales antiguos. Un proveedor externo de identidad también puede exigir MFA individual. TOTP reduce los ataques basados solo en contraseñas, pero un atacante puede retransmitir un código vigente mediante phishing. Una autenticación WebAuthn/FIDO bien implementada ofrece otro nivel de resistencia al phishing. Consulta la guía de autenticación del NIST.

Prueba el alta y la recuperación antes de exigir el segundo factor al equipo. Guarda los códigos de recuperación fuera del teléfono, comprueba los relojes del servidor y el teléfono y documenta el procedimiento de recuperación de la herramienta. El núcleo no tiene columnas estándar de 2FA de empleados que puedas vaciar.

Security Revolution añade TOTP de empleados, códigos de respaldo, controles de acceso, gestión de cabeceras de seguridad y comparaciones con una referencia de archivos; sigue su ayuda para la configuración y recuperación.

Distingue la caducidad de cookies de la inactividad

PS_COOKIE_LIFETIME_BO se mide en horas. Controla la duración de la cookie, no una política general de inactividad. El acceso persistente y las comprobaciones de inactividad difieren según la versión; PrestaShop 1.7.8 tiene una comprobación independiente de última actividad de una hora en el modo de acceso aplicable. Prueba el comportamiento real del cierre de sesión.

PS_PASSWD_TIME_BACK se mide en minutos y se relaciona con la última generación de contraseña. No garantiza una demora entre solicitudes de email de restablecimiento. Añade una limitación de solicitudes independiente cuando haga falta.

Exige HTTPS e inspecciona la cookie real de administración para comprobar los indicadores Secure y HttpOnly y una política SameSite adecuada. La configuración de cookies de sesión de PHP no controla necesariamente todas las cookies de PrestaShop. Bloquea los puestos desatendidos y revoca las sesiones si se compromete un dispositivo o una cuenta.

Demuestra el alta y la recuperación con un empleado normal

1. Usa un empleado identificado con el perfil de permisos previsto, en vez de probar solo como SuperAdmin.
2. Completa el alta, cierra sesión y prueba un acceso nuevo. Confirma que no se pueda alcanzar la ruta protegida saltándose la página del segundo factor.
3. Prueba la recuperación documentada por pérdida del dispositivo con una persona autorizada disponible para ayudar. Confirma qué invalida la acción de recuperación y cómo registra el empleado un dispositivo sustituto.
4. Comprueba el alta de todos los empleados activos, incluidos contratistas y cuentas usadas solo ocasionalmente. Define quién aprueba una excepción y cuándo termina.

El CAPTCHA de formularios de clientes y la autenticación de empleados son superficies independientes. Instalar protección para el acceso de la tienda no demuestra que esté cubierto el acceso al back office; prueba la ruta real de empleados.

Restringe el acceso y detecta los inicios de sesión fallidos

Si tu equipo usa una dirección de oficina estable o VPN, restringe el back office en el proxy o servidor. Conserva una vía de recuperación autorizada y prueba desde direcciones permitidas y denegadas. Con un proxy inverso, configura la gestión fiable de IP de clientes antes de usar reglas IP.

Para Apache 2.4, lo siguiente es un ejemplo para un directorio de administración cuya oficina autorizada usa la red de documentación mostrada. Usa tu propia red aprobada al desplegarlo.

Require ip 203.0.113.10
Require ip 198.51.100.0/24

Limita la frecuencia de los fallos de autenticación mediante un mecanismo probado con la ruta de acceso de tu versión. No deduzcas un fallo de HTTP 200 o 302: los intentos correctos e incorrectos pueden compartir esos códigos. Un filtro fail2ban necesita registros específicos de fallos y pruebas que demuestren que no bloquea accesos correctos.

Los registros del núcleo son parciales. PrestaShop 1.6, 1.7.8 y 8.2 registran las conexiones correctas al back office con el empleado y la IP de origen. La detección de accesos fallidos, el análisis de ubicación y el envío de alertas necesitan controles propios. Conserva juntos los registros de proxy, autenticación y aplicación con marcas temporales sincronizadas.

Las notificaciones personalizadas de acceso deben usar la integración correcta: las versiones antiguas compatibles exponen actionAdminLoginControllerLoginAfter; PrestaShop 9 usa eventos de autenticación Symfony como LoginSuccessEvent. Una alerta de email funcional también requiere listeners registrados, plantillas reales traducidas, una ruta de plantilla, entrega correcta y gestión de fallos.

Permisos de archivos, identidades del alojamiento y errores de caché

Identifica la identidad del proceso PHP antes de cambiar propietarios. Los procesos de trabajo PHP-FPM se ejecutan con el usuario y grupo configurados para el pool, que pueden diferir de Nginx, Apache o un proceso maestro root. Con mod_php, PHP se ejecuta en el proceso Apache. En alojamiento por cuenta o con suPHP, puede ejecutarse con tu usuario de alojamiento.

Para código de aplicación legible ordinario, los modos 755 en directorios y 644 en archivos son puntos de partida habituales. El permiso de ejecución de directorio permite atravesarlo. El propietario, el grupo y las ACL determinan quién puede escribir. Dar al usuario PHP la propiedad de todo el código también permite que PHP comprometido lo reescriba. Prefiere código propiedad del usuario de despliegue y acceso de escritura limitado para la ejecución cuando tu mantenimiento lo permita.

Mantén app/config/parameters.php legible por PHP en PrestaShop 1.7, 8 y 9. La versión antigua 1.6 usa config/settings.inc.php. Aplicar 400 de forma general puede romper la tienda si PHP no es el propietario. No apliques 777 para resolver un error de escritura. PHP vulnerable puede seguir escribiendo en un directorio 755 del que sea propietario.

Corrige un error de escritura de caché tras una migración

1. Lee la ruta exacta del error e inspecciona su propietario, grupo, modo y permisos para atravesar los directorios superiores.
2. Comprueba el proceso de trabajo real de PHP-FPM y la configuración del pool.
3. Concede a la identidad PHP necesaria acceso de lectura, escritura y búsqueda mediante propiedad, un grupo de confianza o ACL.
4. Solo tras reparar el acceso, elimina el contenido generado de la caché en el entorno afectado y caliéntala con el usuario de ejecución previsto.
5. Comprueba espacio en disco, inodos, montajes de solo lectura, SELinux/AppArmor, rutas chroot y umask de despliegue si el acceso sigue fallando.

Este ejemplo presupone que has confirmado que el proceso PHP se ejecuta como www-data y debe ser propietario de esta caché. Usa privilegios elevados para todos los cambios de modo y cambia archivos y directorios por separado.

sudo chown -R www-data:www-data /var/www/html/var/cache
sudo find /var/www/html/var/cache -type d -exec chmod 750 {} +
sudo find /var/www/html/var/cache -type f -exec chmod 640 {} +

Las rutas modernas con escritura incluyen var/cache/, registros, img/, upload/ y download/. La instalación de módulos, los cambios de tema, las traducciones y las actualizaciones necesitan acceso adicional de escritura temporal. Las cachés Smarty de la antigua 1.6 pueden estar en cache/smarty/. Mantén separados los permisos del actualizador de los permisos habituales de la tienda.

En Docker, compara los UID/GID numéricos dentro y fuera del contenedor. Los montajes de enlace conservan la propiedad del host. Los volúmenes con nombre también necesitan inicialización y propiedad adecuadas; no conceden automáticamente acceso a PHP. Evita un chown recurrente de todo el árbol como sustituto de un modelo deliberado de identidades.

Ante fallos de subida, comprueba también los límites de subida de PHP. Si aparece una página en blanco tras chmod, comprueba los permisos para atravesar directorios y el registro PHP. Revisa los permisos del cliente SFTP y umask si las subidas cambian continuamente los modos.

Protege la configuración, las subidas y el entorno PHP

Desactiva la salida de depuración en producción. Establece _PS_MODE_DEV_ en false en config/defines.inc.php y comprueba el control aplicable Parámetros avanzados > Rendimiento > Modo depuración. Registra los errores en un destino protegido. Revisa los ajustes efectivos de la SAPI web en vez de depender de PHP de CLI. Una base mínima incluye display_errors=Off, log_errors=On, expose_php=Off y allow_url_include=Off.

Desactivar funciones de procesos como exec, system, shell_exec, passthru, popen y proc_open puede limitar algunas cargas maliciosas, pero puede impedir tareas legítimas. Los pools PHP-FPM pueden establecer php_admin_value[disable_functions] además de php.ini. Reinicia el servicio correcto, verifica el entorno web y prueba el procesamiento de imágenes, las importaciones y los trabajos PDF. Esto no impide que PHP lea datos en los que tenga permiso de escritura ni use las credenciales de la base de datos.

open_basedir puede limitar rutas, pero necesita todas las rutas temporales y de aplicación legítimas. Trátalo como una restricción adicional, no como un entorno aislado. No expongas un archivo permanente de phpinfo ni de shell de prueba.

Bloquea las rutas HTTP sensibles

Desactiva los listados de directorios. Deniega el acceso público a configuración, registros, copias, volcados SQL, metadatos de repositorios y manifiestos de dependencias. Guarda las copias fuera de la raíz web. Un archivo PHP de parámetros ejecutado correctamente no imprime el array que devuelve, pero la exposición del código fuente o una copia pueden revelar credenciales.

Conserva las rutas necesarias de certificados /.well-known/ al restringir archivos ocultos. No deniegues a ciegas todos los archivos PHP de los módulos: los callbacks, tareas cron y endpoints AJAX antiguos pueden depender de ellos.

Impide que los scripts subidos lleguen a PHP

Cubre img/, upload/ y download/, incluidas extensiones ejecutables alternativas y nombres con varias extensiones. Revisa la configuración real del gestor PHP. Este ejemplo de host virtual Apache 2.4 deniega nombres ejecutables habituales en esas rutas:

<DirectoryMatch "/var/www/html/(img|upload|download)(/|$)">
    <FilesMatch "(?i)\.(php[0-9]?|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

DirectoryMatch debe ir en la configuración del servidor o host virtual. php_admin_flag engine off es específico de mod_php y no debe copiarse sin protección a configuraciones PHP-FPM. Con PHP-FPM, excluye también estas rutas de la ejecución FastCGI.

En Nginx, coloca una ubicación deny para los nombres ejecutables antes de una ubicación regex general de PHP, adáptala a cualquier subdirectorio de la tienda y revisa todas las ubicaciones de gestores. Por ejemplo:

location ~* ^/(img|upload|download)/.*\.(php[0-9]?|phtml|phar)(\.|$) {
    return 403;
}
autoindex off;

Valida la configuración del servidor y prueba después los nombres bloqueados y las imágenes normales, subidas de clientes, descargas y callbacks de pago. Ajusta las reglas a todas las extensiones que tu servidor ejecute realmente.

HTTPS, cabeceras de seguridad y CSP

Instala y renueva un certificado válido, activa SSL y SSL en todas las páginas en Parámetros de la tienda > Configuración en versiones modernas, y verifica las redirecciones HTTP, el proceso de compra y el contenido mixto. En 1.6, la configuración general está en Preferencias. Los navegadores bloquean contenido mixto activo, como scripts, y pueden convertir los medios mixtos a HTTPS. Usa la consola del navegador y el panel de red para encontrarlo.

Redirige al host de confianza configurado. Ten en cuenta la terminación TLS en un proxy para evitar bucles. Añade HSTS solo cuando HTTPS funcione con fiabilidad; usa includeSubDomains solo cuando todos los subdominios afectados admitan HTTPS.

Revisa X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, las restricciones de marcos y una Permissions-Policy adecuada. Prueba los pagos integrados y otras integraciones antes de aplicar restricciones de marcos.

Despliega una Content Security Policy por etapas

default-src proporciona valores alternativos. script-src controla los scripts; style-src, img-src y font-src controlan otros recursos; connect-src controla las conexiones de scripts. frame-src controla los marcos integrados, mientras que frame-ancestors controla quién puede insertar tu página. form-action restringe los destinos de envío de formularios. Considera object-src 'none' para bloquear contenido object y embed y base-uri 'self' para restringir las URL base, después de probar tus integraciones. Establece expresamente base-uri, form-action y frame-ancestors: no heredan de default-src.

1. Empieza con Content-Security-Policy-Report-Only.
2. Inspecciona los diagnósticos del navegador en los flujos de producto, carrito, cuenta, contacto, compra, redirección y 3-D Secure.
3. Para recoger informes, despliega un servicio receptor, configura Reporting-Endpoints con report-to y un respaldo report-uri adecuado, y demuestra que llega una infracción de prueba deliberada.
4. Crea una lista de permitidos a partir de los orígenes realmente necesarios. Elimina los permisos amplios https:, 'unsafe-inline' y 'unsafe-eval' cuando lo permita la compatibilidad con nonces/hashes y plantillas.
5. Pasa a aplicar la política tras probarla y sigue supervisando los informes.

Una cabecera de solo informe no bloquea nada. Sin un receptor funcional, un registro vacío del servidor no dice nada sobre las infracciones. No confíes automáticamente en los orígenes notificados ni los añadas a tu lista de permitidos. Las directivas de informes se definen en CSP Level 3.

Una política que permite 'self' puede seguir permitiendo un script local infectado o un intermediario del mismo origen. Siguen siendo necesarias comprobaciones de integridad de scripts protegidas de forma independiente, supervisión del servidor y código parcheado.

Módulos, acceso a la base de datos y puntos de entrada públicos

Instala módulos de fuentes responsables. Revisa quién los mantiene, los registros de cambios, las correcciones de seguridad y la integridad del paquete. Los paquetes modificados o no fiables pueden contener malware. Figurar en un mercado reconocido no demuestra que el código esté libre de vulnerabilidades.

Desactivar un módulo normalmente bloquea sus rutas estándar ModuleFrontController. Los scripts PHP independientes pueden seguir siendo ejecutables. Antes de desinstalar software sin uso, conserva los datos del negocio y comprueba dependencias, callbacks y tareas programadas; después elimina sus archivos.

La revisión de código debe seguir los datos de las solicitudes a través de la autorización, la validación de tipos, SQL, las escrituras de archivos y el escape de salida. eval o las cargas ejecutables decodificadas requieren atención. file_get_contents obtiene bytes en vez de ejecutarlos, así que revisa el destino y su uso posterior. La ejecución de aserciones de cadena se eliminó en PHP 8. La conversión a entero y pSQL() abordan entradas SQL concretas; no constituyen una revisión de seguridad completa.

Usa una cuenta de base de datos dedicada y limitada a la base de la tienda, no una cuenta de administrador. Concede los privilegios necesarios para las operaciones reales de ejecución y mantenimiento. Evita privilegios globales, FILE o administrativos innecesarios. Restringe el acceso de red a la base de datos y usa una conexión privada si es remota.

Protege o elimina las herramientas públicas de administración de bases de datos. Prefiere una vía privada autenticada o un túnel SSH y desactiva el acceso web con contraseña vacía o root. Un prefijo de tablas distinto no corrige la inyección SQL.

Elimina la carpeta install después de la instalación y comprueba que no vuelva tras una migración o una restauración: un instalador accesible permite a cualquiera volver a ejecutar la instalación y tomar el control de la tienda. En abril de 2026, Sansec encontró más de 200 tiendas PrestaShop con el instalador expuesto.

Acceso Webservice, socios logísticos y retirada de accesos

En Parámetros avanzados > Webservice, desactiva la API si no se usa. Si se usa, emite una clave independiente por integración, restringe recursos y métodos, exige HTTPS, almacena los secretos con seguridad y revoca las claves sin uso. Revisa por separado los clientes y ámbitos de Admin API donde esté desplegada.

Crea la lista de acceso de un operador 3PL a partir de sus solicitudes reales. Los pedidos contienen ID de direcciones, así que el envío puede requerir datos de dirección, país, provincia, transportista y contacto, además de pedidos y detalles de pedido. Concede solo lo que necesite el flujo.

Los permisos de recursos no aíslan campos ni pedidos individuales. Los detalles de pedido pueden revelar campos de coste de compra. Una lista de visualización elegida por el cliente no es una barrera de acceso. Si un socio no debe ver costes o pedidos ajenos, ofrece un endpoint o una exportación filtrados y controlados por el servidor.

Las actualizaciones de seguimiento y los cambios de estado usan vías independientes. Crear un recurso order_histories cambia el estado; añade sendemail=1 para solicitar su email de estado configurado. El estado también debe tener el email activado y una plantilla adecuada. Actualizar un recurso order_carriers cambia el seguimiento; su opción independiente sendemail=1 solicita el mensaje en tránsito, que también necesita una URL de seguimiento del transportista. Ambas opciones no envían email por defecto. Actualiza el seguimiento antes de solicitar el mensaje correspondiente y deduplica los reintentos.

1. Desactiva inmediatamente la cuenta del empleado saliente cuando termine su acceso.
2. Revoca sus claves individuales Webservice, clientes API y accesos a alojamiento, SFTP, SSH, email y terceros.
3. Invalida las sesiones y rota los secretos compartidos que conociera.
4. Conserva la atribución útil de pedidos y auditoría.
5. Revisa las tareas programadas, los responsables y los contactos de recuperación.

Un Perfil es un rol de permisos reutilizable, no un acceso con interruptor de activación. Cambiar o eliminar un Perfil compartido puede afectar a otros empleados. Consulta la guía de Webservice para los conceptos de la API.

Ejemplo práctico: conexión de un almacén

Supongamos que un almacén necesita pedidos pagados y debe devolver el seguimiento, pero no debe recibir los costes de compra. Empieza con un pedido de prueba y la lista real de solicitudes del almacén. Si los permisos estándar de recursos exponen campos fuera de ese acuerdo, aplica el filtrado en tu integración controlada por servidor en vez de confiar en los campos de visualización solicitados por el almacén.

Prueba la conexión en el entorno de pruebas capturando el correo saliente en un buzón de prueba. Recupera los datos acordados de pedido y dirección y después intenta recuperar los costes de compra y un pedido no relacionado mediante el acceso del socio; ningún intento debe revelar datos excluidos. Actualiza el seguimiento antes de solicitar las acciones acordadas de estado y email. Repite el mismo evento del almacén y confirma que la gestión de reintentos impida entradas de historial y mensajes duplicados. Revoca la clave de prueba del almacén y confirma que falle la siguiente solicitud; esto demuestra que puedes terminar la integración además de iniciarla.

Verifica una baja en vez de limitarte a quitar un nombre

Tras los pasos de baja anteriores, prueba que se rechacen tanto la sesión existente del exempleado como un acceso nuevo y que fallen las credenciales API revocadas. Confirma que el resto del equipo pueda seguir trabajando. Si una sesión antigua sigue siendo utilizable, investiga los controles de sesión de la versión o la capa de acceso en vez de suponer que desactivar al empleado la ha invalidado. Comprueba que las direcciones de email de recuperación, las credenciales de tareas programadas y los destinos de copias de seguridad pertenezcan ahora a alguien responsable.

Contrata y delega con acceso controlado

Identifica el cuello de botella antes de añadir ayuda. Revisa la antigüedad de los hilos de soporte abiertos, las demoras entre pago y expedición, los errores de stock, las consultas sin atender y el trabajo que se detiene cuando te ausentas. Mide la primera respuesta a partir de las marcas de tiempo de los mensajes o un informe de soporte; la lista del núcleo no es un panel completo de tiempos de respuesta.

Los ingresos o movimientos bancarios por sí solos no dan el margen neto por pedido. Usa el cálculo siguiente para comparar el coste completo de la ayuda con la contribución adicional que tu tiempo liberado pueda producir de forma realista y ten en cuenta la demanda estacional.

Para incorporar a una persona, crea el rol en Equipo > Perfiles, configura los Permisos y después crea el Empleado con ese perfil y solo el acceso a tiendas pertinente. Prueba el rol iniciando sesión como esa persona, incluidas las URL directas y las acciones de módulos de terceros. Ocultar un menú no es una prueba de autorización suficiente. Restringe estrictamente la instalación de módulos, el Gestor SQL y la gestión de empleados. El permiso de instalar un módulo permite introducir código PHP del servidor, así que trátalo como un privilegio de despliegue.

Documenta el flujo de estados de pedido, las reglas de devoluciones y reembolsos, los procedimientos de stock y los pasos de escalado de soporte. Los Mensajes de pedido predefinidos se seleccionan desde una página de pedido. Los hilos del Servicio al cliente usan su propio comportamiento de firma y respuesta predeterminada; un catálogo compartido de respuestas necesita una integración adecuada de soporte.

Mantén la estrategia de productos, la elección de proveedores, la dirección de marca y la política de clientes bajo una responsabilidad clara. Externaliza tareas definidas cuando el nivel de calidad, la frecuencia, el contexto necesario y el coste lo justifiquen. Compara las tarifas de almacenamiento, recepción, preparación, embalaje, envío, devoluciones y mínimos de un 3PL con tus propios costes.

Da a los proveedores instrucciones escritas, ejemplos de aceptación, un calendario de comunicación y titularidad clara de recursos y credenciales. Reevalúa el trabajo continuado de contratistas cuando la coordinación sea un cuello de botella. La relación laboral depende de las normas locales y de la relación real, no de un umbral de horas semanales. Prefiere hooks, decoración de servicios y puntos de extensión de tema admitidos antes que overrides antiguos exclusivos.

Elige ayuda según el cuello de botella

Haz un cálculo de contratación con tus propios registros: estima los pedidos adicionales que la capacidad liberada pueda atender de forma realista y multiplícalos por la contribución por pedido adicional tras coste de producto, cargos de pago, preparación, devoluciones previstas y otros costes variables. Compara esa contribución con salarios u honorarios, costes empresariales, formación, supervisión y herramientas durante el mismo periodo. Si no hay demanda adicional realista, tampoco hay contribución al crecimiento; cualquier justificación se basa entonces en calidad de servicio, continuidad o carga de trabajo en vez de ingresos supuestos.

Para un contratista de catálogo, por ejemplo, facilita una correspondencia CSV acordada y filas de muestra antes de conceder acceso de importación. Valida las referencias de producto, el idioma y el ámbito de tienda en pruebas, revisa los productos cambiados y aprueba después la importación en producción. Un fotógrafo puede entregar archivos nombrados por referencia sin acceso al back office; la entrega de un especialista no requiere automáticamente acceso a la tienda.

Filtrado de tráfico y tiendas pendientes de migración

Un WAF puede bloquear solicitudes concretas de exploits, limitar abusos y proteger rutas costosas como las URL de búsqueda por facetas. Prueba las reglas con navegación, compra, API y callbacks de proveedores. Robots.txt es una indicación para rastreadores, no un control de acceso. Los bloqueos por país e IP pueden afectar a clientes legítimos, especialmente en redes compartidas.

Cuando un proxy proteja tu tienda, restringe los puertos web del origen a las redes de proxy de confianza y las vías de gestión necesarias. Cubre IPv4 e IPv6 y mantén actualizadas las listas de direcciones. Los registros de correo y DNS antiguos pueden revelar la IP de origen. Mantén el acceso SSH, de correo y del panel de alojamiento bajo reglas independientes.

Los campos de expresión para limitar la frecuencia de Cloudflare varían según el plan: Free ofrece campos basados en rutas, Pro añade coincidencia de consultas y Business añade campos de expresión de IP de origen y user-agent. El recuento por IP es otra capacidad. Advanced Rate Limiting es una oferta Enterprise independiente. Comprueba la disponibilidad actual antes de diseñar una regla contra inundaciones sensible a la consulta.

CAPTCHA puede reducir el abuso en la tienda, pero necesita pruebas de accesibilidad y fallos. reCAPTCHA & hCaptcha Protection cubre los formularios de clientes admitidos; sigue su ayuda para configurarlo.

Customer Extra Info (IP Ban) proporciona información de visitantes y bloqueo IP; sigue su ayuda para configurar el ámbito aplicable.

Usa controles compensatorios mientras migras

Identifica el componente vulnerable exacto y el aviso. Una regla de interceptación en un WAF externo es un parche virtual; modificar el código fuente es un parche directo o una adaptación del parche a una versión anterior. Registra y prueba cada medida temporal y fija una fecha de retirada ligada al plan de actualización.

Para la cadena de ataque antigua de la caché MySQL de Smarty, comprueba la versión afectada y la solución oficial. En 1.7.8, _PS_SMARTY_CACHING_TYPE_ es una constante PHP y controla la carga del recurso de caché MySQL. No es un selector de la página Rendimiento. Verifica el recurso de caché efectivo en ejecución tras la corrección.

Revisa individualmente los puntos de acceso independientes abandonados en vez de bloquear todo el PHP de módulos. La inmutabilidad de archivos es un control opcional del administrador para archivos inventariados individualmente; PrestaShop modifica legítimamente algunos archivos de configuración. Documenta cómo desbloquearlos para mantenimiento y volver a bloquearlos después.

Haz revisable la contención temporal

Para cada regla o adaptación temporal, registra el componente afectado y la versión instalada, el aviso o las pruebas de registros, la solicitud o ruta de código exacta cubierta, el responsable, el procedimiento de reversión y la dependencia de migración que permitirá retirarla. Un bloqueo amplio de palabras sospechosas puede pasar por alto entradas codificadas y rechazar búsquedas legítimas; prueba la vía de explotación confirmada junto a solicitudes normales.

Por ejemplo, un módulo de búsqueda antiguo puede necesitar tanto una corrección específica para una consulta afectada como una regla de tráfico contra solicitudes costosas de rastreadores. Esos controles abordan problemas distintos. Demuestra que se deniega la solicitud bloqueada, que los filtros legítimos siguen funcionando y que no se puede acceder al origen evitando el proxy, y conserva los resultados con el plan de migración. Revisa los eventos observados del WAF antes de aplicarlos para tener en cuenta las llamadas de pago, los rastreadores útiles y el tráfico de clientes.

Supervisión y una revisión práctica

Supervisa PHP, JavaScript y plantillas nuevos y modificados frente a una base de despliegue fiable. Protege esa base por separado, revisa las exclusiones y programa escaneos reales y entrega de alertas si necesitas detección desatendida. Un escaneo manual es una comparación puntual.

Compara el núcleo con la misma versión limpia y los archivos de módulos con paquetes fiables. Revisa cuentas de empleados inexplicables, ajustes de pago alterados, campos de compra desconocidos y scripts inesperados. Los cambios también pueden ser despliegues legítimos; investiga en vez de eliminar automáticamente las coincidencias.

Para una revisión de empleados de solo lectura, sustituye el prefijo de tablas si es necesario:

SELECT id_employee, email, id_profile, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

La tabla estándar de empleados no tiene date_add. Un ID creciente puede ayudar a revisar cuentas desconocidas, pero no es una marca de tiempo de creación. last_connection_date no es un campo de antigüedad de la cuenta.

Desde la raíz de la tienda, estas búsquedas de solo lectura identifican archivos que revisar:

find img upload download -type f -iname '*.php*' -print
find img upload download -type f \( -iname '*.phtml*' -o -iname '*.phar*' \) -print
find . -type f -name '*.php' -mtime -14 -print
find . -type f -name '*.js' -mtime -14 -print
find . -type f -name '*.php' -exec awk 'length($0)>5000 {print FILENAME ":" FNR}' {} +

Las líneas largas y cadenas codificadas pueden ser legítimas. Correlaciona mtime, ctime, marcas de tiempo de creación disponibles, registros e instantáneas. Ctime es el último cambio de estado del inodo, no la creación inicial del archivo; los cambios de propietario y modo pueden actualizarlo.

Supervisa el contenido de inicio, páginas representativas del catálogo y la disponibilidad del proceso de compra, no solo HTTP 200. Comprueba la renovación del certificado por separado. Confirma que el plan de supervisión elegido incluye alertas de certificados y tiempo de respuesta y prueba su entrega a un canal atendido.

Una autocomprobación debe cubrir versiones de software, actualizaciones de módulos, empleados, comparaciones de archivos, restricciones de origen y una copia de seguridad restaurada. Un perfil de empleado de solo lectura no hace automáticamente seguro para un auditor cada punto de configuración de terceros; acuerda expresamente el acceso necesario y el tratamiento de datos. Usa una cuenta temporal para una revisión externa, proporciona acceso de lectura a archivos y registros cuando sea posible y elimina después la cuenta cuando termine el trabajo acordado. La guía de preparación para auditorías te ayuda a preparar esa entrega.

Para una revisión local inicial, Security Scan informa gratuitamente de hallazgos priorizados y pasos de corrección manual. Su examen es de solo lectura y conserva los hallazgos en la tienda; no bloquea tráfico, parchea archivos ni cambia ajustes. Las revisiones programadas y alertas de hallazgos críticos facilitan el seguimiento, pero una puntuación no demuestra la ausencia de infección.

Convierte los hallazgos en la siguiente acción

Conserva cada hallazgo sin resolver con su ubicación, pruebas, responsable y siguiente acción. Una autocomprobación limpia responde solo a las comprobaciones realizadas realmente. Escala los hallazgos que no puedas explicar y repite las comprobaciones pertinentes tras una actualización, cambio de tema, nueva integración o entrega de acceso.

Copias de seguridad y respuesta a incidentes

Haz copias de la base de datos y sus archivos correspondientes con una frecuencia adecuada a la pérdida de pedidos que puedas tolerar. Mantén varios puntos de restauración, cifra los archivos sensibles y conserva una copia fuera del servidor con credenciales independientes. Fija la retención según las necesidades de recuperación y negocio, no un número universal de días.

Usa credenciales protegidas de base de datos y una herramienta de copias que compruebe errores. En comandos inline de crontab, los signos de porcentaje necesitan un único escape; poner el flujo de copias en un script evita esa trampa. Prueba una restauración en una tienda aislada, incluidos acceso de clientes, imágenes, pedidos y configuración. Consulta la guía de copias de seguridad.

Si sospechas una intrusión

1. Contén la tienda en una capa fiable de servidor o proxy. Impide nuevas compras o exposición de datos y conserva el acceso de quienes respondan al incidente.
2. Conserva las pruebas del incidente: base de datos, archivos, registros pertinentes y marcas de tiempo. Guarda las copias con seguridad antes de una limpieza destructiva.
3. Identifica el punto de entrada y la persistencia, incluidas cuentas de empleados, tareas programadas y contenido inyectado en la base de datos.
4. Desde un dispositivo y entorno limpios, revoca sesiones y rota las credenciales expuestas de alojamiento, SSH, SFTP, base de datos, empleados, correo y pagos/API. Coordina los cambios de configuración para que la recuperación funcione.
5. Reconstruye con paquetes de software fiables y restaura datos limpios; después parchea el punto de entrada. No traslades un tema, árbol de imágenes o base de datos comprometidos sin examinarlos.
6. Prueba la compra, los pagos, los reembolsos, el email y las integraciones antes de reabrir. Supervisa de cerca cualquier recurrencia.

Si usas Apache para devolver un estado de mantenimiento, configura ErrorDocument 503 por separado. Una reescritura con R=503 no sirve por sí sola la sustitución como página de mantenimiento.

Informa a tu alojamiento, proveedor de pago y equipos de respuesta según corresponda. Según el artículo 33 del GDPR, notifica a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo de 72 horas desde que tengas constancia, salvo que sea improbable el riesgo para las personas. El artículo 34 exige generalmente informar a las personas afectadas sin dilación indebida si es probable un riesgo alto, sujeto a sus excepciones. Usa la guía de brechas del EDPB y tu procedimiento de protección de datos.

Antes de reabrir, confirma que la salida de depuración está desactivada, se han eliminado las herramientas temporales, los endpoints vulnerables están corregidos o eliminados, las credenciales y los accesos de empleados están controlados, las copias se restauran y las alertas llegan al responsable.

Acuerda las decisiones de recuperación de antemano

Anota quién puede autorizar la contención, contactar al alojamiento y al proveedor de pago, recuperar copias protegidas y aprobar la reapertura. Registra la tolerancia a perder pedidos y la interrupción aceptable y mide después una restauración aislada frente a esos límites. Las copias pueden contener los mismos archivos maliciosos o contenido inyectado en base de datos que la tienda de producción, así que elegir el punto de restauración requiere pruebas de cuándo empezó la intrusión.

Revisa qué datos personales conservan tu tienda, módulos, exportaciones y registros. Elimina las copias innecesarias mediante un proceso de conservación acordado y restringe el resto. Recoger datos adicionales sin necesidad comercial aumenta lo que puede obtener un atacante; copiarlos a pruebas o a un archivo de incidentes también exige acceso controlado.

Qué preguntar a tu desarrollador o agencia

• ¿Qué componente y versión exactos están expuestos y qué pruebas relacionan el cambio propuesto con esa exposición?
• ¿Qué controles están en el alojamiento, proxy, tienda o módulo y quién mantiene cada uno tras la entrega?
• ¿Qué funciones existentes del tema, recorridos de pago, mercados e integraciones de socios se probaron en el entorno de pruebas, incluidas acciones denegadas y recuperación?
• ¿Cuál es el procedimiento de cambio y reversión y cómo se conciliarán los pedidos o pagos recibidos durante una migración?
• ¿Dónde están la referencia de despliegue, los resultados de restauración y las pruebas de entrega de alertas y quién responde cuando falla una comprobación?
• ¿Qué reglas temporales, credenciales y herramientas deben retirarse y qué reparaciones quedan fuera de la evaluación acordada?

Preguntas de los propietarios

¿El alojamiento gestionado se encarga de la seguridad de la tienda?

Pide por escrito el límite de mantenimiento. El mantenimiento del sistema operativo y del servidor no determina quién actualiza tu instalación de PrestaShop, tema o módulos. Confirma quién revisa los avisos, aprueba cambios de tienda y responde a alertas de aplicación según tu acuerdo real.

¿Y si mi equipo no puede usar IP fijas de oficina?

Evalúa una salida VPN gestionada o un proxy de acceso basado en identidad con autenticación individual. Prueba las ubicaciones reales de trabajo del equipo y la recuperación por pérdida de dispositivo antes de exigirlo. Conserva una vía de recuperación aprobada en vez de ampliar la lista de permitidos cada vez que alguien viaje.

¿Debo instalar un analizador inmediatamente si sospecho una intrusión?

Acuerda primero el método de examen con el responsable de respuesta. Instalar software cambia archivos y puede alterar pruebas útiles o la referencia que intentas comparar. Conserva el estado afectado y organiza la inspección desde un entorno de confianza antes de añadir herramientas a una instalación presuntamente comprometida.

¿Cómo debo enviar registros o credenciales a quien me ayuda?

Acuerda un canal de transferencia protegido y facilita solo lo necesario para la investigación. Oculta los datos personales no relacionados y los secretos en capturas rutinarias y adjuntos de tickets; si se necesita un registro original como prueba, consérvalo aparte bajo acceso controlado. Usa acceso individual temporal en vez de pegar una contraseña compartida del propietario en un ticket.

¿Pueden quedarse las reglas temporales tras la migración?

Revisa cada regla frente a la exposición real de la tienda migrada. Elimina las excepciones obsoletas y retira una regla compensatoria solo después de demostrar que la ruta vulnerable subyacente está corregida o ya no existe. Conserva las defensas y la supervisión útiles si siguen cumpliendo una finalidad documentada.