Seguridad e-commerce y multi-CMS: PrestaShop, Magento

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Una tienda online no es un blog con un botón de comprar. Es una plataforma que procesa dinero, guarda datos de cliente y toca información de tarjeta, y eso la convierte en un objetivo económico, no oportunista. Los atacantes ya no buscan «defacear» tu portada: buscan quedarse dentro semanas, robar cada tarjeta que pasa por el checkout y monetizar los pedidos. Si gestionas un e-commerce sobre PrestaShop, WooCommerce, Magento, Joomla o Drupal, tu superficie de ataque real vive en las capas que casi nadie audita: módulos, extensiones, plantillas y el propio flujo de pago.

Esta guía es la página de referencia del cluster de seguridad de e-commerce y multi-CMS de PathSentinel. Aquí te damos el mapa completo —qué se rompe en cada plataforma, por qué y cómo defenderlo— y desde cada sección enlazamos a los análisis técnicos, herramientas de comprobación e investigaciones que profundizan en cada frente.

Por qué el CMS que eliges cambia tu perfil de riesgo

Todas las tiendas comparten el mismo objetivo del atacante —el dato de pago— pero cada plataforma llega hasta él por un camino distinto. Entender esa diferencia es lo que separa una defensa genérica («ten un plugin de seguridad») de una defensa que de verdad cierra la puerta por la que van a entrar.

• WordPress + WooCommerce: el riesgo se concentra en el ecosistema de plugins y temas de terceros, y en un panel de administración expuesto a fuerza bruta y robo de sesión.
• PrestaShop: los módulos de terceros son, con diferencia, la primera vía de compromiso, especialmente vía inyección SQL en parámetros mal saneados.
• Joomla: las extensiones (componentes, módulos y plugins) concentran la mayoría de CVE explotados en tiendas y portales.
• Magento / Adobe Commerce: objetivo predilecto de Magecart y del skimming de tarjetas por su cuota en comercios que mueven volumen.
• Drupal: menos volumen de tiendas, pero fallos de ejecución remota de código (RCE) devastadores cuando no se parchea a tiempo.

Si aún no tienes claro sobre qué corre tu tienda —o la de un cliente que auditas—, empieza por identificarlo: cómo saber qué CMS usa una web y por qué importa para su seguridad. Y si quieres el cuadro comparativo detallado de fallos por plataforma, tienes la referencia en vulnerabilidades típicas por CMS: guía comparativa.

WooCommerce y WordPress: el checkout más popular es también el más atacado

WooCommerce mueve una porción enorme del comercio pyme, y esa popularidad es precisamente su superficie. El core de WooCommerce es razonablemente sólido; el problema casi siempre está alrededor: un plugin de pago desactualizado, un tema anulado con puerta trasera, un formulario de checkout inyectado con JavaScript malicioso o un panel /wp-admin sin doble factor.

La prioridad en WooCommerce es blindar el flujo donde el cliente introduce sus datos y donde se comunican los pagos. Lo desglosamos en WooCommerce seguro: proteger checkout, pagos y datos de cliente. Y como toda tienda maneja datos personales y, a menudo, información de tarjeta, conviene entender qué te obliga la ley y el estándar de pago: fugas de datos en WooCommerce: RGPD y PCI-DSS para tu tienda.

PrestaShop: los módulos son la puerta de entrada número uno

Si tuviéramos que señalar el vector más rentable contra el e-commerce hispanohablante, serían los módulos de PrestaShop. Son código de terceros con acceso privilegiado a la base de datos, muchas veces desarrollados sin revisión de seguridad, y a menudo desatendidos durante años. Un solo parámetro sin sanear en un módulo puede abrir toda la tienda.

El patrón de ataque más habitual es la inyección SQL a través de un parámetro de módulo: el atacante manipula una variable que el módulo pasa directamente a una consulta, extrae credenciales o inyecta un fichero, y desde ahí despliega un skimmer sobre el checkout. Hemos diseccionado paso a paso ese ataque en inyección SQL en PrestaShop vía parámetro de módulo: anatomía del ataque, y explicamos por qué los módulos concentran el riesgo en módulos de PrestaShop: por qué son la puerta de entrada nº1 y cómo auditarlos.

Hay un agravante que multiplica todo lo anterior: los módulos «nulled» (versiones pirateadas de módulos de pago). No solo son ilegales; una parte enorme llega con backdoors preinstaladas. Es un mercado organizado que investigamos en módulos «nulled» de PrestaShop: el mercado de backdoors que infecta tu tienda. Si sospechas que ya te ha pasado, verifícalo en dos minutos: ¿tu PrestaShop está hackeado? cómo comprobarlo.

Joomla: las familias de extensiones que más webs comprometen

Joomla sigue sosteniendo portales y tiendas con integraciones a medida, y su punto débil recurrente son las extensiones de terceros. Un puñado de componentes populares acumula históricamente la mayoría de compromisos, casi siempre por SQLi, subida de ficheros sin validar o inclusión local de archivos. El core actualizado protege razonablemente; una extensión olvidada, no.

Repasamos las familias reincidentes en extensiones de Joomla vulnerables: las familias que más webs comprometen, y si ya notas comportamientos raros, tienes la guía de verificación en cómo saber si tu web Joomla ha sido hackeada: síntomas y verificación. Para quien está eligiendo plataforma, la comparación honesta de superficie de ataque está en Joomla vs WordPress: cuál es más seguro y qué cambia en el ataque.

Magento y Magecart: el skimmer que roba tarjetas sin que lo notes

Magento (hoy Adobe Commerce) es el hogar histórico de Magecart: grupos especializados en inyectar skimmers de JavaScript en el checkout para copiar los datos de tarjeta en el mismo momento en que el cliente los teclea, antes de que se cifren hacia la pasarela. El robo ocurre en el navegador de la víctima, la transacción se completa con normalidad y no hay ningún síntoma visible: por eso muchas tiendas descubren la brecha meses después, por el banco.

Cómo funciona el ataque de principio a fin lo explicamos en Magecart en Magento: cómo un skimmer roba tarjetas sin que lo notes. Y como esperar a la llamada del banco no es una estrategia, deberías escanear tu checkout de forma activa: detectar un skimmer en Magento: cómo escanear tu checkout ya.

Drupal: por qué no actualizar te deja expuesto a RCE

Drupal mueve menos tiendas, pero sus fallos críticos son de los más graves del panorama. El caso de manual es Drupalgeddon: la familia de vulnerabilidades de ejecución remota de código —Drupalgeddon 2 (CVE-2018-7600) es el ejemplo canónico— que permitió tomar el control de sitios sin autenticar y que se explotó de forma masiva en cuestión de horas tras publicarse el parche. La lección es incómoda pero clara: en Drupal, el tiempo entre el aviso de seguridad y tu actualización es tu ventana de exposición.

Desarrollamos el porqué en Drupalgeddon y RCE en Drupal: por qué no actualizar te deja expuesto, y para saber si tu instalación está en riesgo por versión, usa cómo saber la versión de tu Drupal y si está en riesgo por estar desactualizada.

El hilo común: skimmers, formjacking y el dato de pago

Cambia el CMS, pero el objetivo final rara vez cambia. La mayoría de los compromisos de e-commerce terminan en lo mismo: un skimmer web (formjacking) que intercepta el formulario de pago. Es el denominador común de PrestaShop, Magento, WooCommerce y cualquier tienda que teclee tarjetas en su propio dominio. Reconocer el patrón —scripts sospechosos, dominios de terceros nuevos en el checkout, cambios en integridad de la página de pago— es una competencia transversal que todo operador de tienda debería tener. La cubrimos en qué es un skimmer de tarjetas web (formjacking) y cómo detectarlo.

Comparativa rápida: dónde ataca cada plataforma

CMS	Vector principal	Objetivo típico	Primer control
WooCommerce / WP	Plugins y temas de terceros; panel expuesto	Skimmer en checkout, robo de sesión admin	2FA + inventario y parcheo de plugins
PrestaShop	Módulos (SQLi por parámetro) y módulos nulled	Backdoor + skimmer de tarjetas	Auditoría de módulos, eliminar nulled
Joomla	Extensiones vulnerables (SQLi, file upload)	Webshell, defacement, spam SEO	Retirar extensiones sin mantenimiento
Magento	Magecart / skimming de JavaScript	Robo de tarjeta en tiempo real	Monitor de integridad del checkout
Drupal	RCE por versión desactualizada (Drupalgeddon)	Control total del servidor	Parcheo inmediato de avisos críticos

Cumplimiento: PCI DSS y RGPD no son opcionales

Si tu tienda toca datos de tarjeta, entras en el ámbito de PCI DSS, y si manejas datos de clientes en la UE, en el de RGPD. Muchas pymes creen que «eso es solo para bancos»; no lo es. La buena noticia es que para el comercio pyme el cumplimiento real suele ser más asumible de lo que parece, sobre todo si delegas el dato de tarjeta en la pasarela y no lo tocas nunca. Aterrizamos qué te exigen de verdad y cómo cumplirlo en PCI DSS para tiendas online pyme: qué te exigen de verdad y cómo cumplirlo.

Las referencias oficiales de partida son el PCI Security Standards Council para el estándar de pago y el OWASP Top 10 para las categorías de riesgo web (inyección, componentes vulnerables, integridad de software y datos). Para consultar el detalle técnico de una vulnerabilidad concreta por su identificador, la fuente autorizada es la National Vulnerability Database (NIST NVD).

Autoalojado vs alojado: elegir modelo también es una decisión de seguridad

No todo se resuelve parcheando. A veces la decisión de fondo es quién asume la carga de seguridad. Una tienda autoalojada (PrestaShop, WooCommerce, Magento propio) te da control total y también toda la responsabilidad del parcheo, el hosting y el cumplimiento. Un modelo alojado tipo Shopify traslada buena parte de esa carga al proveedor, a cambio de menos control. No hay respuesta universal; hay una respuesta correcta para tu tamaño y tu equipo. La analizamos sin sesgo en Shopify vs tienda autoalojada: qué modelo es más seguro para tu pyme, y si dudas entre las dos plataformas autoalojadas más comunes, en PrestaShop vs WooCommerce: comparativa de seguridad real.

Por dónde empezar hoy

La seguridad de e-commerce no es un producto, es una disciplina continua. Pero puedes ordenar el trabajo en cuatro movimientos concretos, válidos sea cual sea tu CMS:

• Inventaría tu superficie: identifica CMS, versión y, sobre todo, cada módulo, extensión y plugin de terceros. Lo que no sabes que tienes es lo que te va a comprometer.
• Elimina lo prohibido: nada de módulos ni temas nulled, y fuera todo componente sin mantenimiento activo del desarrollador.
• Protege el checkout: monitoriza la integridad de la página de pago y vigila scripts y dominios de terceros nuevos. Ahí es donde se juega el dinero.
• Parchea con disciplina: trata cada aviso de seguridad crítico como una emergencia con reloj, no como una tarea de backlog.

Cada uno de esos movimientos tiene su guía específica en las páginas enlazadas a lo largo de este cluster. Empieza por identificar tu plataforma y verificar si ya hay un compromiso activo; el resto se ordena solo desde ahí.