Seguridad en PrestaShop: buenas prácticas para tu tienda

Si vendes con PrestaShop, la seguridad no es un extra del hosting: es parte de cobrar. Un back office débil, un módulo de origen dudoso o una versión sin actualizar no se notan el martes a las once. Se notan cuando la tienda no carga, aparecen pedidos raros o no puedes entrar al admin.

Esta guía es de buenas prácticas: qué cuidar, en qué orden y cuándo pedir ayuda. Es defensiva a propósito. No vas a encontrar recetas de ataque ni «trucos» para forzar una tienda. Si ahora mismo tienes un problema (caída, usuarios que no reconoces, actualización a medias), usa el formulario de la derecha: ¿Tienes problemas en tu PrestaShop?

En Wecomm llevamos años como agencia PrestaShop Expert. Lo que sigue es el criterio que usamos con tiendas reales, no un checklist copiado de un foro.

Qué es seguridad en PrestaShop (y qué no es)

Seguridad en PrestaShop es mantener el control de tu tienda: quién entra, qué código corre, dónde viven los datos y si puedes volver atrás. No es un sello eterno ni un antivirus mágico. El core es software mantenido; el riesgo suele estar en lo que le pones encima y en lo que dejas sin parchear.

Tampoco es «poner HTTPS y olvidarte». El certificado evita que alguien lea el tráfico en claro. No decide si tu empleado comparte la contraseña del BO, si un módulo viejo sigue expuesto o si la última copia se corrompió hace tres meses.

Una forma útil de pensarlo: tu escaparate (la tienda pública) y tu almacén (el back office, la base de datos, los módulos) no se protegen igual. El cliente ve productos. Quien administra ve pedidos, clientes y la capacidad de cambiar precios. Ahí es donde duele un acceso indebido.

Cuánto cuesta un incidente de verdad

No hay una cifra oficial de «cuánto cuesta un hackeo de PrestaShop» que puedas usar con rigor. Inventarla sería humo. Sí hay contexto de sector: el IBM Cost of a Data Breach Report 2025 (Ponemon, 600 organizaciones, marzo 2024 a febrero 2025) sitúa el coste medio global en 4,44 millones de USD. En retail baja a 3,54; en finanzas sube a 5,56; en sanidad, 7,42.

Tu tienda no es un hospital. El gráfico sirve para otra cosa: un incidente no es «formatear y ya». Hay horas de tienda parada, confianza, emails a clientes, pasarela que revisa, copias que hay que validar. En una pyme eso se come el margen de meses.

Por eso el mantenimiento no es un gasto estético. Es el seguro barato comparado con restaurar a ciegas un viernes de campaña. Si vienes de una versión antigua, el salto de rama también es seguridad: en PrestaShop 9 el stack (PHP reciente, Symfony LTS) deja de arrastrar piezas que ya no reciben parches.

Por dónde suelen entrar

El Verizon Data Breach Investigations Report 2025 no habla de PrestaShop. Habla de cómo empiezan muchas brechas en general. Tres números merecen sitio en tu cabeza:

• 22% de las brechas empiezan con credenciales robadas.
• 16% empiezan con phishing.
• En el patrón de ataques básicos a aplicaciones web, el 88% usa credenciales robadas.
• Los terceros aparecen implicados en un 30% de los casos (proveedores, integraciones, alguien con acceso que no es tu equipo).

Traducción para tu BO: contraseña única, gente de baja sin acceso, y no instalar «el módulo que me pasó un contacto» sin saber quién lo mantiene. El phishing no se arregla con un parche de core: se arregla no haciendo clic, no reenviando el admin por WhatsApp y no reutilizando la misma clave que en el correo.

Cinco capas que sí puedes controlar

No intentes «blindar internet». Cubre cinco capas, en este orden. Si una falla, las otras limitan el daño.

1. Hosting. PHP en versión soportada, SSL, copias fuera de la máquina, actualizaciones del panel. Un PrestaShop en PHP abandonado es deuda, no ahorro.
2. Core. La versión de PrestaShop y el Update Assistant. Parches de seguridad del proyecto, no «ya funciona, no toco».
3. Módulos y tema. Cada extra es código con permiso para ejecutarse. Menos módulos, fuentes conocidas, versiones al día.
4. Back office. Quién entra, con qué permiso y desde dónde. Aquí Verizon y tu tienda se dan la mano.
5. Pagos y datos. La tarjeta no debería vivir en tu servidor. La pasarela tokeniza; tú guardas lo mínimo.

Si montas o rediseñas catálogo, el mismo criterio aplica al proyecto: diseño de tiendas online con mantenimiento, no una instalación huérfana. Y si estás eligiendo CMS, la libertad de PrestaShop incluye esta responsabilidad; en la comparativa PrestaShop vs Shopify lo dejamos explícito.

Actualiza el core y los módulos

La práctica número uno de PrestaShop (y la que más se aplaza) es actualizar. El proyecto publica correcciones. Si te quedas dos ramas atrás, heredas agujeros que ya tienen parche. No es teoría: es el ciclo normal de cualquier CMS.

Hazlo con método, no un domingo en producción:

1. Copia de seguridad de archivos y base de datos antes.
2. Entorno de prueba (staging) con la misma versión de PHP.
3. Update Assistant o el flujo oficial de tu rama. Documentación en devdocs.prestashop-project.org.
4. Prueba checkout, fichas, módulos de envío y pago.
5. Pasa a producción en ventana controlada, no en pleno pico de ventas.

Los módulos se actualizan igual que el core: uno a uno, con nota de compatibilidad. Un módulo «que funciona» en 1.7 no es inocente en 8 o 9; a veces ni carga, a veces carga mal. Si la tienda es crítica y no tienes staging, eso ya es un problema de proceso, no de software.

Cierra el back office

El 88% del patrón web de Verizon no pide un exploit sofisticado: pide una clave que ya circula. En PrestaShop el back office es esa puerta.

• Contraseña larga y única para cada empleado. Un gestor de contraseñas, no un Excel.
• Permisos mínimos. Quien solo gestiona pedidos no necesita instalar módulos.
• Bajas de verdad. Cuando alguien deja la empresa, se desactiva el usuario el mismo día.
• Doble factor (2FA). El core aún no lo trae de serie de forma nativa y estable en todas las ramas. Usa un módulo de un editor de confianza, no el primer resultado de un foro. No afirmes que «PrestaShop ya incluye 2FA» si tu versión no lo tiene.
• URL del admin no compartida en redes ni en capturas. Renombrar la carpeta del BO es endurecimiento básico, no un secreto militar.
• Sin debug en producción. El modo depuración enseña rutas y errores a cualquiera que los vea.

Si varios comerciales entran con la misma cuenta «Admin», has perdido la pista de quién tocó un precio. Eso no es ciberseguridad de película: es control operativo.

Instala módulos solo de fuentes de confianza

Aquí se rompen más tiendas que por «un ataque avanzado». Un módulo nulled, un zip de Telegram o un «pack premium gratis» es código que no auditas, con actualizaciones que no existen y, a menudo, con puerta de atrás incluida. No hace falta detallar cómo funciona: el consejo es no instalarlo.

Fuentes razonables:

• El Addons Marketplace oficial, o el editor con nombre, soporte y changelog.
• Módulos que tu agencia mantiene y puede actualizar cuando salga PrestaShop nuevo.
• Cero copias «crackeadas». El ahorro del primer mes lo pagas en limpieza.

Revisa el inventario: módulos instalados que ya no usas, temas viejos, perfiles de prueba. Cada pieza extra es superficie. Si no sabes para qué está, desactívalo en staging y luego quítalo con copia hecha.

Hosting, HTTPS y copias que se pueden restaurar

HTTPS es el mínimo. Sin él, el navegador avisa y los datos viajan en claro. Con él, aún necesitas un hosting que actualice PHP, aísle cuentas y haga copias fuera del mismo disco.

Una copia «que el hosting dice que existe» no es un plan de recuperación. Pregunta: ¿cada cuánto?, ¿cuántos días se retienen?, ¿incluye base de datos?, ¿quién la restaura un sábado? Si la respuesta es vaga, no tienes backup: tienes esperanza.

En el servidor, evita dejar carpetas de instalación o de desarrollo publicadas. No expongas listados de directorios. No dejes credenciales en archivos de ejemplo. Son hábitos de higiene, no un curso de hacking.

Pagos y datos de tus clientes

Tu obligación no es «guardar tarjetas para ir más rápido». Es no guardarlas si puedes evitarlo. Usa pasarelas que tokenizan o redirigen (Redsys, Stripe, PayPal, el TPV que ya tengas). El módulo oficial o el del banco; no un puente opaco.

Los datos de cliente (email, dirección, historial) ya son suficientes para un incidente grave. RGPD no se cumple con un banner: se cumple minimizando, acotando accesos y sabiendo qué harías si hay que comunicar. Eso es proceso, no un plugin de cookies.

Si un módulo «mejora el checkout» pidiendo más permisos de los que necesita, párate. El checkout es zona sensible. Mejor un flujo aburrido y controlado que un atajo opaco.

Checklist mensual de seguridad

Quince minutos al mes evitan el trimestre de fuego. Márcalo en el calendario, no «cuando haya tiempo».

• ¿Hay actualizaciones de core, tema o módulos pendientes?
• ¿PHP sigue en una versión que PrestaShop y el hosting soportan?
• ¿Usuarios del BO: todos reconocibles, todos necesarios?
• ¿Algún módulo nuevo instalado sin que lo pidieras?
• ¿La última copia se puede restaurar? Fecha y tamaño tienen sentido.
• ¿HTTPS, pago y envío funcionan en una compra de prueba?
• ¿El modo depuración está apagado en producción?

Si tres meses seguidos la respuesta es «no he mirado», no tienes un plan: tienes inercia. En tiendas con ventas serias, ese ritmo lo lleva alguien (interno o agencia), no «el que pueda».

Si sospechas un problema

Señales habituales: back office que no carga, usuarios que no creaste, redirecciones raras, CPU disparada, pedidos fantasma, avisos de la pasarela. No improvises «a ver si tocando esto…» en caliente.

Orden defensivo, en alto nivel:

1. Pon la tienda en mantenimiento o baja el catálogo al público si el daño puede seguir.
2. No borres pruebas a lo loco: anota hora, qué ves, qué cambió.
3. Restaura desde una copia que sepas buena, no desde la de hace una hora si el problema ya estaba.
4. Cambia contraseñas del BO, FTP/SFTP, base de datos y panel de hosting. Avisa al equipo.
5. Contacta con hosting y con quien mantenga la tienda. Si no tienes a nadie, cuéntanoslo o usa el recuadro de la derecha.

No pagues «limpieza milagrosa» a un desconocido que te escribe por el formulario. Y no publiques capturas del admin con la URL y la sesión a la vista.

Preguntas frecuentes

¿PrestaShop es seguro?

El core, actualizado y bien alojado, es una base sólida usada por miles de tiendas. El riesgo habitual no es «PrestaShop es inseguro»: es una instalación sin parches, módulos de origen desconocido o un back office compartido. La plataforma no se mantiene sola.

¿Hace falta el doble factor?

Sí, sobre todo si varias personas entran al BO o si el admin se abre desde sitios distintos. Mientras tu rama no lo traiga nativo, un módulo de un editor reconocido es la vía seria. No lo sustituye una contraseña «muy rara» reutilizada.

¿Puedo usar módulos nulled o de foros?

No. Ahorras la licencia y aceptas código sin soporte ni actualizaciones. Es una de las formas más tontas de perder la tienda. Compra el módulo o no lo uses.

¿Cada cuánto actualizo?

Cuando salga un parche de seguridad, en cuanto puedas probarlo. Las actualizaciones menores, con cadencia mensual o al publicar el proyecto. Las de rama (7→8, 8→9) se planifican: staging, módulos compatibles y ventana sin campaña.

¿Qué hago si ya tengo la tienda comprometida?

No intentes «limpiar a mano» sin copia buena. Mantenimiento, restauración conocida, rotación de claves y un profesional que revise módulos y usuarios. El formulario de esta página sirve justo para eso: ¿Tienes problemas en tu PrestaShop?

El siguiente paso

La ciberseguridad de una PrestaShop no es un producto que se instala un viernes. Es un hábito: actualizar, acotar accesos, no instalar basura y poder restaurar. Si eso lo tienes cubierto, duermes mejor y vendes con menos sorpresas.

Si no lo tienes, o ahora mismo la tienda te está fallando, no hace falta que lo dejes «para cuando pueda». Somos agencia PrestaShop: revisión, actualizaciones y un interlocutor. Usa el formulario de la derecha o pide presupuesto y te decimos el siguiente paso, sin teatro.

Comparte este artículo

LinkedInXWhatsAppCopiar enlace