Señales de que tu tienda PrestaShop necesita una auditoría de seguridad (y cómo hacer una comprobación previa por tu cuenta)
Última actualización: junio de 2026.
La mayoría de las tiendas PrestaShop no necesitan comprar un producto de seguridad. Necesitan conocer su exposición real, y muchos propietarios, sinceramente, no la conocen, porque no está pasando nada visiblemente raro. Un skimmer puede permanecer durante semanas en el proceso de pago mientras los pedidos siguen entrando con normalidad. Un módulo vulnerable puede quedarse años sin parchear hasta que alguien lo detecta en un escaneo. El objetivo de una revisión de seguridad no es meter miedo; es sustituir el “creo que probablemente estamos bien” por una respuesta clara y basada en evidencias. Este artículo recoge las señales concretas que justifican mirar más de cerca y te da una comprobación que puedes hacer en unos diez minutos antes de decidir si necesitas ayuda externa.
Las señales que de verdad importan
No son hipótesis. Cada una de ellas es algo que hemos visto convertirse en un incidente real en tiendas reales. Léelas como factores de riesgo: cuanto más encajen con tu caso, más merece la pena dedicar tiempo a una auditoría estructurada.
Estás usando una versión antigua o sin soporte de PrestaShop
PrestaShop 1.6 lleva mucho tiempo fuera de soporte, y la mayor parte de la rama 1.7.x ya no recibe correcciones de seguridad. Incluso en 8.x, una instalación que va unas cuantas versiones menores por detrás puede estar sin parches para vulnerabilidades conocidas públicamente. Un núcleo antiguo es el mayor indicador de exposición, porque los atacantes no necesitan encontrar un fallo nuevo: simplemente escanean en busca de los que ya están documentados. Si no puedes decir qué versión exacta usas sin comprobarlo, eso ya es una señal.
Tus módulos llevan años sin actualizarse
Esta es la verdadera superficie de ataque en la mayoría de las tiendas. El núcleo recibe atención; los módulos de terceros se deterioran en silencio. Hay un largo historial: la inyección SQL en blockwishlist, la inyección de plantillas del lado del servidor basada en Smarty (SSTI) que permitió la ejecución remota de código en varios módulos, y un flujo constante de fallos menos conocidos. Un módulo que instalaste una vez y olvidaste es un punto de entrada perfecto precisamente porque nadie lo vigila. Si tu lista de actualizaciones de módulos muestra muchas actualizaciones pendientes, o módulos de proveedores que ya no existen, trátalo como una señal de alarma.
Tu administración está en la ruta por defecto, sin limitación de intentos ni 2FA
Un panel de administración accesible desde una URL predecible, sin protección contra fuerza bruta y sin autenticación de dos factores, es una invitación abierta para bots de relleno de credenciales y de prueba de contraseñas. Funcionan constantemente y no necesitan ser sofisticados: solo necesitan una contraseña débil o reutilizada de una cuenta de empleado.
No tienes WAF y la IP de origen está expuesta
Si tu tienda está directamente en Internet sin un firewall de aplicaciones web, cada petición maliciosa llega a tu código de aplicación sin filtrar. Peor aún: si usas una CDN pero tu IP de origen real se está filtrando (en el historial DNS, cabeceras de correo o un subdominio antiguo), los atacantes pueden saltarse la protección por completo y atacar directamente el servidor.
Archivos inexplicables, núcleo modificado o cuentas de administración que no reconoces
Archivos PHP sueltos en la raíz web, archivos del núcleo que difieren de una versión limpia, o una entrada en tu lista de empleados que nadie del equipo creó: cualquiera de estas cosas puede significar que ya has sido comprometido. Las puertas traseras están diseñadas para parecer aburridas y permanecer en silencio, así que rara vez se anuncian.
Un proceso de pago o formulario de pago que “se ve ligeramente extraño”
Esta es la señal que más puede costar. Los skimmers de tipo Magecart inyectan unas pocas líneas de JavaScript que copian en silencio los datos de la tarjeta mientras los clientes los escriben y luego los envían al servidor de un atacante. La página sigue funcionando. El pedido se completa. Solo se filtran los datos de la tarjeta. Si tu proceso de pago se percibe sutilmente distinto, con un campo extra, un cambio de diseño o un script que no recuerdas haber añadido, tómatelo en serio. Hemos explicado exactamente cómo funciona uno de estos casos en nuestro artículo sobre la anatomía de un ataque Magecart en un skimmer de PrestaShop.
Sin monitorización de integridad de archivos ni copias de seguridad externas
Si no tienes forma de detectar que un archivo ha cambiado, no puedes distinguir una tienda limpia de una comprometida, y normalmente te enterarás por un cliente o por tu procesador de pagos. Y si tus únicas copias de seguridad viven en el mismo servidor (o nunca has probado realmente una restauración), una intrusión o un disco fallido pueden acabar con el negocio, no solo con el día.
Estás almacenando más datos de clientes de los que necesitas
Cada campo extra que conservas es una responsabilidad que asumes. Almacenar datos completos de tarjetas, guardar años de datos personales sin una política de retención o registrar detalles sensibles convierte una brecha de “vergonzosa” en un problema de PCI-DSS y GDPR con peso financiero y legal real. Los datos más seguros son los que nunca guardaste.
Una comprobación de 10 minutos
Antes de pedir ayuda a nadie, incluidos nosotros, haz esto por tu cuenta. No cuesta nada y te dice mucho:
- Confirma tu versión exacta de PrestaShop y comprueba si sigue teniendo soporte. Si es 1.6.x o una 1.7.x temprana, ya tienes la respuesta.
- Abre la lista de actualizaciones de módulos en tu panel de administración y cuenta las actualizaciones pendientes. Anota cualquier módulo de proveedores que hayan desaparecido.
- Lista tus empleados administradores. Mira la tabla
ps_employeeo la página Equipo y verifica que cada cuenta con acceso al panel de administración es una que reconoces. - Compara los archivos del núcleo con una copia limpia de la misma versión de PrestaShop. Cualquier modificación en
/classes,/controllerso la raíz que no hayas hecho tú merece revisión. - Ordena la raíz web por fecha de modificación. Los archivos modificados recientemente que no puedes justificar son la forma más rápida de detectar una puerta trasera.
- Confirma que tus copias de seguridad existen fuera del servidor y que se restauran de verdad. Una copia de seguridad que nunca has probado es una esperanza, no una copia de seguridad.
Si las seis comprobaciones salen limpias, eso es realmente tranquilizador, y puede que no necesites gastar ni un céntimo. Si alguna te deja intranquilo, esa inquietud es la señal útil.
Si tienes acceso por shell o a la base de datos, tres comandos de solo lectura
Confirman algunas de las comprobaciones anteriores y son estrictamente de solo lectura: listan y comparan, no cambian nada. Ajusta el prefijo de tabla ps_ al tuyo.
# 1. List every account with back-office access — look for anyone you don't recognise
SELECT id_employee, email, lastname, firstname, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;
# 2. Spot recently-modified PHP files in the webroot (a common backdoor tell)
find /path/to/your/shop -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %p\n' \
| sort
# 3. Confirm your stored PrestaShop version, then compare it to the supported list
mysql -e "SELECT value FROM ps_configuration WHERE name='PS_VERSION_DB';"La consulta de empleados es la forma más rápida de detectar una cuenta de administración fraudulenta; un correo desconocido o una fila active=1 que nadie creó es una señal seria. El comando find muestra archivos tocados en los últimos 30 días: compara cada uno con el trabajo que realmente hiciste. Nada de esto demuestra por sí solo una intrusión, pero cualquier cosa inexplicable aquí es exactamente esa “señal útil” que merece escalarse.
La parte honesta: diagnostica antes de comprar
Este es el giro que la mayoría de los argumentos de venta de seguridad se saltan. La respuesta correcta a estas señales casi nunca es “compra un producto”. Es “averigua qué está mal de verdad”. A veces la solución está en la configuración o el alojamiento: un servidor mal configurado, un WAF ausente, un origen expuesto; en ese caso, una auditoría de alojamiento es el paso relevante, no un módulo. A veces se trata de endurecimiento: cerrar la ruta de administración, añadir limitación de intentos y 2FA, que es donde un módulo de código abierto como Security Revolution se gana su sitio, pero solo cuando hayas confirmado que esa es la brecha. Y a veces hace falta una limpieza porque algo ya ha entrado, que es un trabajo específico por sí mismo.
Esa es la razón completa por la que merece la pena hacer primero una auditoría de seguridad: mapea tu exposición real y te dice en cuál de esos tres caminos estás, para que no gastes dinero resolviendo un problema que no tienes. La inicias introduciendo la URL de tu tienda en la página de auditoría de seguridad; se ejecuta una comprobación de preparación de solo lectura sobre la URL y solo entonces se encarga la auditoría.
Si entregar acceso te pone nervioso, debería hacerlo. Ese instinto es correcto, y diseñamos el proceso alrededor de él. La auditoría se realiza en modo solo lectura: miramos, no escribimos y nunca tocamos tu base de datos de clientes. Hemos documentado exactamente qué significa eso y a qué accedemos o no en nuestra guía de preparación para la auditoría de tienda, que vale la pena leer antes de hacer el pedido para saber con precisión qué estás aceptando. Seguridad y rendimiento suelen ir de la mano, así que si ya estás evaluando la salud de tu tienda también merece la pena revisar los servicios expertos más amplios y la auditoría de rendimiento.
Haz hoy la comprobación de diez minutos. Si sale limpia, disfruta de la tranquilidad: te la has ganado gratis. Si no, ahora sabes lo suficiente para hacer la pregunta correcta, que vale mucho más que cualquier producto individual.
Preguntas frecuentes
¿Una auditoría de seguridad limpia una infección o solo la detecta?
Una auditoría diagnostica: mapea tu exposición y te dice si algo ya ha entrado. La limpieza es un trabajo separado y específico, porque eliminar una puerta trasera de forma segura significa encontrar todos los puntos de entrada, no solo el que has visto, y después cerrar el agujero que permitió la entrada para que no vuelva. La auditoría es lo que te dice si necesitas una limpieza y hasta qué profundidad debe llegar. Desconfía de cualquier promesa del tipo “lo escaneamos y lo arreglamos de una sola vez”; una puerta trasera silenciosa y persistente rara vez desaparece de forma tan limpia.
Uso un PrestaShop 8 actual con todo actualizado. ¿Aun así necesito una auditoría?
Posiblemente no, y es una buena posición. Un núcleo actual con módulos actualizados elimina los riesgos más importantes y más escaneados. Las preguntas restantes que responde una auditoría son las que las actualizaciones no cubren: si tu IP de origen se filtra detrás de la CDN, si la ruta de administración permite fuerza bruta, si tienes monitorización de integridad de archivos y una copia de seguridad externa probada, y si estás conservando más datos de clientes de los que deberías. Si la comprobación de diez minutos también sale limpia en esos puntos, estás realmente en buena forma.
¿Necesitaréis mi contraseña de administración o una copia de mi base de datos?
No. Una auditoría de seguridad empieza solo con la URL de tu tienda y se ejecuta en gran medida desde fuera hacia dentro. Cuando una comprobación necesita mirar dentro del panel de administración, basta con una cuenta de empleado de solo lectura, y nunca pedimos ni hacemos una copia de tus datos de clientes o pedidos. El modelo completo de acceso está en la guía de preparación para la auditoría de tienda: léela antes de hacer el pedido para saber exactamente qué implica.
¿Cómo distingo entre una intrusión real y una falsa alarma en la comprobación?
A menudo no puedes hacerlo por tu cuenta, y ese es el límite honesto de una comprobación personal: está pensada para levantar señales, no para confirmarlas. Un archivo modificado recientemente podría ser una actualización legítima; un empleado desconocido podría ser un antiguo contratista. El trabajo de la comprobación es decirte si debes mirar más a fondo. Cuando aparece algo inexplicable y no puedes justificarlo, ese es el punto en el que una revisión externa se paga sola, porque confirmar “esto está bien” tiene el mismo valor que confirmar “esto no lo está”.
¿Con qué frecuencia debería hacer la comprobación?
La versión de diez minutos es lo bastante sencilla como para hacerla cada trimestre y después de cualquier cambio importante: una actualización de PrestaShop, un nuevo módulo de pago, un cambio de tema o una rotación de personal que afecte al acceso de administración. Las dos comprobaciones que merece la pena automatizar en vez de repetir a mano son la monitorización de integridad de archivos y las copias de seguridad externas probadas; cuando funcionan de forma continua, casi todo lo demás consiste en confirmar que nada se ha desviado.
Comentarios
Aún no hay comentarios. ¡Sé el primero!
Sé el primero en hacer una pregunta o compartir una opinión útil.
Dejar un comentario
Comparte una pregunta, un detalle de instalación o una opinión que pueda ayudar a otro lector.