Refuerzo de seguridad en PrestaShop: la lista de comprobación completa

Una tienda PrestaShop es un objetivo atractivo por una razón sencilla: se encuentra justo en el cruce entre el dinero y los datos personales: flujos de pago con tarjeta, nombres y direcciones de clientes, historial de pedidos y un panel de administración accesible desde cualquier lugar de internet. La mayoría de los ataques que recibe no son ingeniosos: son automatizados, indiscriminados y buscan esa única casilla que olvidaste marcar. Esta página es esa lista de casillas. Es la lista maestra para reforzar la seguridad de una tienda PrestaShop, ordenada para que las medidas de mayor impacto y menor esfuerzo aparezcan primero, y con cada tema más profundo enlazado a la guía que lo trata como corresponde.

Revisado en junio de 2026. Estos controles se aplican a PrestaShop 1.7, 8 y 9 (el panel de administración de PS9 funciona sobre Symfony 6.4); mantenemos esta lista actualizada a medida que cambian los avisos de seguridad y las fechas de soporte de PHP.

Úsala como una lista de comprobación, no como un ensayo. Trabaja de arriba abajo: los elementos del Nivel 1 cierran las puertas que los escáneres automatizados tantean cada día, y puedes aplicar la mayoría desde tu panel de administración o tu panel de alojamiento en una tarde. Si quieres cubrir el mismo terreno en lenguaje sencillo y sin jerga, empieza primero por nuestra guía en lenguaje claro para propietarios de tiendas y vuelve aquí para el repaso completo.

Cómo usar esta lista de comprobación

Cada elemento de abajo es un control con un responsable claro y un beneficio claro. Cuando un control es lo bastante amplio como para merecer su propio tutorial — configuración de 2FA, reglas de .htaccess, SSL, bloqueo de bots — esta página te da el "qué y por qué" en un párrafo y luego enlaza a la guía con el paso a paso. Esa estructura de centro y radios es deliberada: aquí tienes el mapa completo sin que volvamos a explicar reCAPTCHA por quinta vez, y sigues el enlace cuando estés listo para configurar algo de verdad.

Una decisión de enfoque antes de empezar: la mayoría de estos controles tratan de reducir la superficie de ataque (menos puertas), y algunos tratan de detectar y recuperarse cuando algo consigue entrar (alarmas y salidas de emergencia). Una tienda segura necesita ambas cosas. Una tienda con una contraseña de administración de 16 caracteres y sin copias de seguridad está a una mala actualización de módulo de tener una semana muy complicada.

Nivel 1 — Imprescindibles (haz esto esta semana)

1. Cambia el nombre del directorio de administración

PrestaShop ya instala tu carpeta de administración con un sufijo aleatorio (algo como admin8f3k2) precisamente por este motivo, pero muchas tiendas actualizadas desde versiones antiguas siguen usando un /admin o /adminXXXX fácil de adivinar que los escáneres prueban primero. Cambia el nombre de la carpeta por FTP/SFTP o desde el gestor de archivos de tu alojamiento a algo que nadie pueda adivinar (evita palabras obvias como backoffice, manage o panel: también se escanean). PrestaShop detecta el cambio en el siguiente inicio de sesión; después, actualiza tu marcador y comunica la nueva URL a tu equipo. ¿Y qué implica? La mayor fuente individual de tráfico de fuerza bruta contra el panel de administración son bots golpeando URL de inicio de sesión previsibles. Mueve la puerta y la mayoría nunca la encontrará.

2. Contraseñas de administración fuertes y únicas, y limpieza de cuentas

Cada cuenta del panel de administración debe usar una contraseña larga y única (16+ caracteres), generada y guardada en un gestor de contraseñas, y nunca reutilizada en otro sitio. Igual de importante: abre Parámetros avanzados → Equipo → Empleados y elimina todas las cuentas que ya no necesiten acceso. El inicio de sesión de administración inactivo de un antiguo freelance es pura superficie de ataque sin ningún beneficio. Ya que estás ahí, confirma que nadie haya creado discretamente una cuenta que no reconozcas.

3. Fuerza HTTPS en todas partes

Ejecutar el proceso de pago y el inicio de sesión sobre HTTP sin cifrar en 2026 no es un riesgo que se acepta, es un defecto que se corrige. HTTPS protege credenciales, datos de tarjeta e información personal en tránsito, y PrestaShop tiene un interruptor integrado para imponerlo en Parámetros de la tienda → General → Activar SSL más Activar SSL en todas las páginas. Si aún no tienes un certificado instalado y forzado en todo el sitio, sigue nuestra guía de configuración de SSL y HTTPS: cubre la instalación del certificado, los dos ajustes de PrestaShop y la corrección de las advertencias de contenido mixto que suelen causar problemas.

4. Mantén PrestaShop y PHP actualizados con parches

La inmensa mayoría de las tiendas PrestaShop comprometidas ejecutaban una versión con una vulnerabilidad pública conocida y ya corregida. Mantente en una versión con soporte, suscríbete a los avisos de seguridad de PrestaShop y nunca uses una compilación de PHP sin soporte (7.4 y 8.0 ya han superado sus fechas de soporte de seguridad). Antes de cualquier actualización del núcleo: haz una copia de seguridad completa, prueba en una copia de preproducción y confirma que tus módulos sean compatibles. ¿Y qué implica? Aplicar parches no es vistoso, pero "íbamos una versión por detrás" es la frase más habitual en el análisis posterior a una brecha.

5. Reduce lo que revelan tus páginas de error y cabeceras

Asegúrate de que el modo depuración esté desactivado en producción: confirma que _PS_MODE_DEV_ es false en config/defines.inc.php, y comprueba que Parámetros avanzados → Rendimiento → Modo depuración esté desactivado, para que una traza de pila nunca entregue a un atacante tus rutas de archivo, el prefijo de tus tablas o las versiones de tus librerías. Una página de depuración filtrada es un mapa gratuito de tu instalación.

Nivel 2 — Control de acceso

6. Activa la autenticación de dos factores para el panel de administración

2FA significa que una contraseña de administración robada por sí sola no basta para iniciar sesión: el atacante también necesita el código de tu teléfono. Esto cierra de una vez los ataques de reutilización de credenciales robadas y el phishing, y es el control de acceso de mayor valor que puedes añadir. La configuración completa, incluidas las políticas de contraseñas y el endurecimiento de sesiones, tiene su propia guía: autenticación de dos factores, políticas de contraseñas y seguridad de administración para PrestaShop.

7. Limita la frecuencia y bloquea los inicios de sesión fallidos

Las herramientas de fuerza bruta prueban miles de contraseñas. Ponles un límite: activa un bloqueo temporal tras un puñado de intentos fallidos (una política habitual es un bloqueo de 15 minutos tras cinco fallos, y un bloqueo largo o veto de IP tras veinte). PrestaShop no limita de forma agresiva los inicios de sesión de administración por sí solo, así que esto suele gestionarse en el WAF/perímetro o con un módulo de seguridad.

8. Restringe el acceso de administración por IP

Si tu equipo inicia sesión desde direcciones fijas (oficina, casa, salida de una VPN), limita el directorio de administración a esas IP con una regla .htaccess (Require ip ... en Apache) o desde tu cortafuegos. Este único control elimina de raíz la mayor parte del tráfico de fuerza bruta y reutilización automatizada de credenciales, porque las solicitudes del atacante ni siquiera llegan al formulario de inicio de sesión. Las reglas exactas están en nuestra guía de seguridad y rendimiento para .htaccess.

9. Ajusta los permisos de los empleados

El sistema de perfiles de PrestaShop en Parámetros avanzados → Equipo → Permisos es granular: úsalo. Un editor de contenidos no necesita gestionar módulos; un agente de atención al cliente no necesita ajustes de servidor ni SQL Manager. Da a cada perfil el mínimo que necesita, vuelve a auditar la lista de empleados de forma periódica y elimina a cualquiera que ya no esté. El privilegio mínimo significa que un único inicio de sesión de personal comprometido no puede arrasar toda la tienda.

Nivel 3 — Refuerzo del servidor y los archivos

En nginx, el equivalente es una regla de denegación para carpetas sensibles de la aplicación y PHP subido. Las rutas varían según la estructura del alojamiento, así que prueba primero con nginx -t y una solicitud en preproducción.

location ~* ^/(app|var|vendor|config|classes|controllers|override)/ {
    deny all;
}

location ~* /(img|upload)/.*\.php$ {
    deny all;
}

Las reglas del servidor y las cabeceras de seguridad deben comprobarse juntas después del refuerzo.

10. Establece los permisos de archivo correctos

Los directorios deben ser 755 y los archivos 644. Nada en una instalación de PrestaShop debería ser jamás 777 (escribible por cualquiera): si un tutorial te dice que hagas chmod 777 para "hacer que funcione", el problema es ese tutorial. Los archivos escribibles por cualquiera son exactamente lo que necesita una explotación de subida de archivos para dejar una puerta trasera.

11. Bloquea el acceso web directo a directorios sensibles

Varias carpetas de PrestaShop nunca deberían ser accesibles desde un navegador: /app/, /cache/, /config/, /var/, /vendor/, /translations/, /mails/ y similares. El .htaccess incluido con PrestaShop cubre algunas, pero verifícalas y añade lo que falte (y confirma que Options -Indexes esté definido para que el listado de directorios esté desactivado, porque de lo contrario filtra tu lista exacta de módulos a cualquier curioso). El conjunto completo de reglas — directorios sensibles, listado, archivos ocultos — está en la guía de seguridad y rendimiento para .htaccess.

12. Añade cabeceras de seguridad HTTP

Las cabeceras de seguridad indican al navegador que active protecciones adicionales. El conjunto de mayor valor para una tienda PrestaShop: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN (protección contra clickjacking), Strict-Transport-Security (añádela solo cuando HTTPS esté bien consolidado; consulta el punto 3), Referrer-Policy: strict-origin-when-cross-origin y una Content-Security-Policy desplegada primero en modo de solo informe para no romper los scripts de tu propio tema. CSP en particular es tu defensa más fuerte contra un capturador de tarjetas que inyecte un script malicioso en el proceso de pago, que es exactamente cómo se desarrolla el ataque en nuestro recorrido por la anatomía de un ataque de tipo Magecart en PrestaShop.

13. Coloca un WAF delante de la tienda

Un cortafuegos de aplicaciones web filtra el tráfico malicioso antes de que toque PrestaShop. El plan gratuito de Cloudflare bloquea muchos patrones comunes y añade protección DDoS; Cloudflare Pro y ModSecurity (con OWASP Core Rule Set) van más allá. Un WAF también es tu primera línea de defensa contra presión volumétrica y generada por rastreadores, incluido el aluvión de búsqueda facetada con ?q= que puede convertir discretamente las propias URL de filtros de PrestaShop en una denegación de servicio autoinfligida, algo que diseccionamos y defendemos con reglas de Cloudflare en sobrevivir al aluvión de ?q=.

Nivel 4 — Higiene de módulos y API

14. Audita los módulos instalados sin piedad

Cada módulo es código ejecutándose dentro de tu tienda, y cada módulo sin usar es riesgo sin recompensa. Tres reglas: elimina todo lo que no uses activamente (desactivado no basta: los archivos PHP siguen siendo accesibles); nunca ejecutes módulos nulled (piratas), que suelen venir con puertas traseras; y mantén todo actualizado, revisando el sitio del desarrollador para ver avisos. Los módulos de terceros obsoletos son el vector de brecha más común en PrestaShop después del núcleo sin parches.

15. Bloquea o desactiva la API Webservice

Si usas la API Webservice de PrestaShop (Parámetros avanzados → Webservice), concede a cada clave los recursos mínimos que necesite en lugar de acceso completo, elimina las claves sin usar, exige HTTPS y restringe por IP cuando puedas. Si no la usas, cambia Activar el servicio web de PrestaShop a No. Una clave de API con demasiados permisos es una exportación completa de datos esperando a ocurrir.

16. Elimina datos predeterminados y de muestra

Los productos de demostración sobrantes, las categorías de muestra y las páginas CMS predeterminadas no sirven de nada y dan pistas sobre la antigüedad y la estructura de tu instalación. Límpialos cuando la tienda ya sea real.

Nivel 5 — Abuso en la interfaz pública y control de bots

17. Detén el spam en los formularios con reCAPTCHA

Los formularios de contacto, el registro de cuentas, las reseñas y las suscripciones al boletín son las puertas por las que entran los bots para inundar tu tienda de basura y tantear debilidades. reCAPTCHA detiene el ruido automatizado sin bloquear a clientes reales, configurado y ajustado a la manera de PrestaShop en nuestra guía de reCAPTCHA para PrestaShop.

18. Bloquea bots malos y visitantes abusivos

Más allá del CAPTCHA, querrás filtrar tráfico que no tiene ningún motivo para estar en tu tienda: extractores de contenido, escáneres de vulnerabilidades y clientes que martillean puntos de acceso. La aplicación real de medidas contra bots hostiles corresponde a un WAF, reglas a nivel de servidor o un módulo de seguridad dedicado, no a los ajustes del núcleo de PrestaShop; Parámetros de la tienda → Tráfico & SEO solo ayuda con robots.txt e indicaciones para rastreadores, que los bots bien comportados respetan pero los escáneres ignoran. La geolocalización puede restringir países enteros, pero tampoco es un control contra escáneres. El conjunto de herramientas más profundo está en control de visitantes: bloqueo de bots malos y tráfico no deseado. Para tratar con reincidentes concretos por IP — el cliente que sigue haciendo pedidos fraudulentos, la dirección que no deja de tantear — consulta información extra de clientes y vetos de IP.

19. Protege con contraseña lo que aún no está listo para el público

Contenido de preproducción, páginas mayoristas, una colección aún no lanzada: cualquier cosa que esté en línea pero que todavía no deba indexarse ni navegarse debería estar detrás de una contraseña en lugar de depender de una URL oscura. Los enfoques para PrestaShop están en protección con contraseña para PrestaShop.

Nivel 6 — Monitorización, respuesta y recuperación

20. Monitorización de integridad de archivos

La forma más rápida de detectar un compromiso es darse cuenta en el momento en que cambia un archivo que no debería. La monitorización de integridad de archivos (FIM) toma huellas de tus archivos de PrestaShop y de módulos y te alerta cuando uno se modifica de forma inesperada, que es exactamente lo que ocurre en cuanto un atacante inyecta código en un controlador o en una plantilla de pago. Es el sistema de alerta temprana que convierte una brecha silenciosa en una corrección el mismo día.

21. Vigila tus registros de acceso

Revisa los registros de acceso del servidor en busca de señales: ráfagas de solicitudes desde una sola IP, accesos repetidos al inicio de sesión de administración, solicitudes de archivos que no existen (sondeo de vulnerabilidades) y POST inesperados. Si tu alojamiento ofrece fail2ban, apúntalo a tus registros de PrestaShop para que los reincidentes se veten automáticamente. Saber cómo se ve lo normal es lo que te permite detectar lo anormal.

22. Monitorización de disponibilidad y certificados

Un monitor gratuito como UptimeRobot vigilando caídas, caducidad de SSL y picos repentinos de tiempo de respuesta cumple una doble función: detecta interrupciones y señala el consumo de recursos de, por ejemplo, una carga de criptominería o una inundación de tráfico antes de que lo hagan tus clientes.

23. Copias de seguridad automatizadas, probadas y externas

Haz copias diarias de archivos y base de datos, conserva copias en al menos dos lugares (servidor más nube externa) y, esta es la parte que todos se saltan, prueba de verdad una restauración cada trimestre. Una copia de seguridad que nunca has restaurado es una esperanza, no un plan. Cifra con GPG las copias externas de la base de datos (contienen datos de clientes). Conserva algo como 30 días de copias diarias y unos meses de semanales; el almacenamiento es barato y un punto de restauración limpio es lo que se interpone entre tú y empezar de cero.

24. Escribe el plan de respuesta a incidentes antes de necesitarlo

Cuando una tienda se ve comprometida, el peor momento para decidir el siguiente paso es a las 2 de la madrugada. Documéntalo de antemano: a quién llamar (alojamiento, procesador de pagos, especialista en seguridad), cómo entrar en modo mantenimiento sin perder pedidos en curso, dónde está la última copia limpia, cómo restaurarla y qué verificar después. Si lo peor ya ha ocurrido, nuestra guía de respuesta ante brechas de datos paso a paso recorre toda la secuencia, incluidas las obligaciones de notificación del RGPD.

El caso especial: una tienda que aún no puedes actualizar

La lista anterior asume que puedes aplicar parches. Muchas tiendas reales no pueden: un tema muy personalizado, un módulo crítico sin versión compatible, una migración de plataforma a seis meses vista. Eso no significa que estés indefenso. El parcheo virtual, las reglas de WAF en el perímetro y el refuerzo específico pueden blindar una vulnerabilidad conocida sin tocar el núcleo, dándote tiempo para actualizar correctamente. El manual completo para tiendas atrapadas en una versión antigua es refuerzo avanzado de PrestaShop para tiendas que aún no puedes actualizar.

Dónde encajan los módulos, y dónde no

La mayor parte de esta lista no cuesta nada salvo atención: ajustes que ya controlas en el panel de administración, interruptores del panel de alojamiento, una hora con tu .htaccess. Preferimos que hagas eso antes de comprar nada. Donde un módulo se gana su lugar es en los puntos que son tediosos o imposibles de hacer a mano: principalmente 2FA y refuerzo del inicio de sesión, y monitorización continua de integridad de archivos que vigila por ti cada cambio de archivo en lugar de obligarte a revisar registros a ojo. Nuestros módulos de seguridad en mypresta.rocks cubren esas capas, configurados desde tu panel de administración y sin editar el núcleo para que una actualización no los deshaga. ¿Y qué implica? Pagas por automatizar los controles que una persona no puede mantener manualmente, no por sustituir la higiene gratuita que hace la mayor parte del trabajo.

El resumen honesto

La seguridad en PrestaShop no es un proyecto que se termina; es un estándar que se mantiene. La buena noticia es que los ataques que golpean tu tienda son en su mayoría torpes y automatizados, lo que significa que los controles básicos y aburridos — parches, cambiar el nombre del directorio de administración, forzar HTTPS, contraseñas fuertes, 2FA, copias de seguridad que hayas probado de verdad — detienen a la inmensa mayoría. Avanza por esta lista, salta a las guías más profundas cuando llegues a cada control y pon un recordatorio trimestral recurrente en tu calendario para repasarla otra vez. Las tiendas que sufren brechas casi nunca son las que hicieron las cosas aburridas; son las que pensaban hacerlas.

Comprobación rápida: lista todas las cuentas del panel de administración con una consulta

El punto 2 te pide limpiar la lista de empleados y confirmar que nadie haya creado discretamente una cuenta que no reconozcas. El panel de administración te lo muestra en Parámetros avanzados → Equipo → Empleados, pero una consulta SQL de solo lectura es más rápida de revisar y más difícil de ocultar para una interfaz de administración manipulada. Ejecútala contra tu base de datos (ajusta el prefijo ps_ para que coincida con el tuyo): solo lee, no cambia nada:

-- Read-only: every back-office account, newest first.
-- Flag SuperAdmins (id_profile = 1) you don't recognise, and any
-- account whose date_add is recent but that nobody on your team created.
SELECT id_employee, email, id_profile, active, date_add, last_connection_date
FROM ps_employee
ORDER BY date_add DESC;

Dos tipos de filas merecen una segunda mirada: cualquier id_profile = 1 (SuperAdmin) que no esperabas y cualquier cuenta cuyo date_add caiga dentro de un periodo en el que no estabas incorporando personal. Un SuperAdmin malicioso creado durante un compromiso es una de las primeras cosas que planta un atacante para mantener una vía de regreso, y sobrevive a una limpieza de malware si solo saneas archivos. Desactívalo desde el panel de administración en lugar de eliminarlo si primero quieres conservarlo como evidencia.

Preguntas frecuentes

Tengo una tienda pequeña y no tengo desarrollador. ¿Cuánto de esto puedo hacer realmente por mi cuenta?

La mayor parte del Nivel 1 y el Nivel 2 — cambiar el nombre de la carpeta de administración, usar contraseñas fuertes, forzar HTTPS, activar 2FA, limpiar cuentas, ajustar permisos — son tareas del panel de administración o del panel de alojamiento que no requieren código. Los elementos a nivel de servidor (permisos de archivo, .htaccess, cabeceras) son donde tiene sentido pedir ayuda a tu proveedor de alojamiento o a un desarrollador. Empieza por la versión en lenguaje sencillo de nuestra guía para propietarios de tiendas y sigue desde ahí.

¿Necesito un módulo de seguridad o basta con el refuerzo gratuito?

El refuerzo gratuito hace la mayor parte del trabajo y deberías aplicarlo primero en cualquier caso. Un módulo solo se gana su lugar en dos tareas que son tediosas o imposibles a mano: 2FA más refuerzo del inicio de sesión, y monitorización continua de integridad de archivos que vigila cada cambio de archivo en lugar de obligarte a revisar registros a ojo. Si pagas, pagas por automatizar eso, no por sustituir los fundamentos gratuitos.

¿El plan gratuito de Cloudflare basta como WAF?

Para una tienda típica bloquea muchas pruebas comunes y añade protección DDoS, así que merece la pena activarlo. Pero el plan gratuito no puede hacer coincidencias sobre cadenas de consulta ni agentes de usuario en reglas de limitación de frecuencia, algo importante si te están atacando activamente; por ejemplo, limitar un aluvión de búsqueda facetada con ?q= requiere Pro. Cubrimos exactamente dónde se queda corto el plan gratuito en el refuerzo avanzado para tiendas que aún no puedes actualizar.

¿Con qué frecuencia debería repasar esta lista?

Pon un recordatorio trimestral recurrente en tu calendario: veinte minutos para confirmar que PrestaShop y los módulos están actualizados, que 2FA está activo para todos, que las cuentas de exempleados han desaparecido y que una copia de seguridad se restaura de verdad. La seguridad en PrestaShop no es un proyecto que se termina; es un estándar que se mantiene.

Mi tienda está en una versión que no puedo actualizar ahora mismo. ¿Estoy simplemente expuesto?

No, pero pasas de aplicar parches a parcheo virtual: reglas de WAF en el perímetro, bloqueo del origen para que los atacantes no puedan saltárselo y correcciones específicas para los fallos concretos que señalan tus registros y avisos. El manual completo para tiendas atrapadas en una versión antigua es refuerzo avanzado de PrestaShop para tiendas que aún no puedes actualizar.

Sigue leyendo

• Protege tu tienda PrestaShop: una guía en lenguaje claro para propietarios de tiendas — el mismo terreno sin jerga, para propietarios no técnicos.
• Anatomía de un ataque de tipo Magecart en una tienda PrestaShop 1.7.x — contra qué defienden realmente estos controles, desde dentro.
• Respuesta ante brechas de datos: qué hacer si hackean tu tienda — el manual tranquilo, paso a paso, para las primeras horas.