Skimmers: cómo detectar si roban las tarjetas en tu tienda
En resumen
Un skimmer es código que copia las tarjetas de tus clientes en el pago y las envía a un tercero mientras la tienda sigue vendiendo con normalidad; suele descubrirse cuando el banco o la pasarela preguntan por fraudes. Se esconde en JavaScript, en módulos o plantillas de pago modificados y en la base de datos, y está hecho para que el administrador no lo vea. Es una brecha de datos: en España hay que notificarla a la AEPD en 72 horas.
Un skimmer es un trozo de código que copia los datos de tarjeta de tus clientes mientras pagan y los envía a un tercero. La tienda sigue vendiendo con normalidad, los pedidos llegan y el dinero entra. Lo normal es enterarse semanas después, cuando el banco o la pasarela te preguntan por qué tantas tarjetas defraudadas compraron en tu web.
Por Jose SorianoPublicada: Última actualización: 6 min de lectura
Cómo funciona un skimmer
Hay dos variantes, y conviene conocerlas porque se detectan de forma distinta:
- Lector de formulario. Si tu pasarela pide la tarjeta en tu propia página (un formulario integrado), el skimmer es un JavaScript que lee esos campos al escribir o al pulsar «Pagar» y manda una copia a un servidor del atacante. El pago sigue su curso: el cliente no nota nada.
- Formulario falso. Si tu pasarela redirige a su página o usa un iframe que el skimmer no puede leer, el atacante pinta su propio formulario de tarjeta en tu checkout. El cliente mete los datos, recibe un error y a continuación aparece el pago real. Es lo que describía PrestaShop en la campaña de julio de 2022: un formulario de pago falso inyectado en el checkout.
El envío de los datos se disfraza: peticiones a dominios con nombres que imitan servicios de analítica o de CDN, datos codificados dentro de una petición de imagen, o guardados en el propio servidor para recogerlos más tarde.
Cómo entra en la tienda
Casi siempre por la misma puerta: un módulo o plugin con un fallo conocido. En PrestaShop, Friends of Presta indica expresamente en varios avisos que el fallo se ha usado para instalar skimmers de forma masiva, por ejemplo en stripejs, supercheckout, simpleimportproduct, leoblog o jmsmegamenu. Tengo la lista en módulos de PrestaShop con vulnerabilidades. En WooCommerce el patrón es el mismo con plugins de WordPress.
Las otras entradas habituales son contraseñas robadas de administradores o del hosting, y scripts de terceros comprometidos (un chat, un píxel o una librería que cargas desde fuera y que alguien modifica en origen).
Dónde se esconde
En PrestaShop
- Plantillas del checkout del tema (
themes/tu-tema/templates/checkout/) o la cabecera común. - Archivos del núcleo que intervienen en el pedido, como
classes/Cart.phpoclasses/PaymentModule.php, o un override nuevo enoverride/. - Un módulo enganchado a
displayHeadero a los hooks del pago, a veces con un nombre que imita a uno legítimo. - La base de datos: un
<script>guardado enps_configurationo en un módulo de bloques HTML, que se pinta en todas las páginas o solo en el pedido.
En WooCommerce
- La tabla
wp_options: scripts guardados en opciones del tema o de plugins que permiten añadir código personalizado a la cabecera o al pie. - El
functions.phpdel tema o un plugin falso, a menudo enwp-content/mu-plugins/, que no aparece en el listado normal de plugins. - Archivos JavaScript legítimos del tema o de un plugin con unas líneas añadidas al final.
- Contenido de entradas, widgets o bloques que se cargan en la página de pago.
Por qué el administrador no lo ve
Los skimmers están hechos para no dejarse ver por quien puede quitarlos:
- Solo se activan en la página de pago, que el dueño casi nunca recorre entero.
- No actúan si hay sesión de administrador o si detectan las herramientas de desarrollo del navegador abiertas.
- Muchos actúan una sola vez por visitante (guardan una marca) o solo en ciertos países.
- El código va ofuscado, partido en trozos o cargado desde la base de datos, así que no aparece buscando en los archivos del tema.
- En PrestaShop, varios avisos explican que el ataque inicial oculta la ruta del módulo y en los logs solo se ve
POST /.
Cómo detectarlo
- Compra de prueba como un cliente cualquiera: desde un navegador sin sesión, en incógnito, con un móvil si puedes. Fíjate en si aparece un formulario de tarjeta que no debería estar, un paso de más o un error antes del pago real.
- Mira las peticiones del checkout: con
F12→ Network abierto antes de llegar al pago, revisa a qué dominios se conecta la página. Cada dominio debe tener una explicación: tu pasarela, tu analítica, tu CDN. Uno que no sabes qué es, a investigar. - Compara los scripts que se cargan en el checkout con los de una copia antigua o con los de la página de inicio: lo que solo aparece en el pago es sospechoso. El análisis gratuito lista los scripts externos de la portada y las versiones visibles de módulos y plugins con fallos publicados.
- Revisa la integridad de los archivos frente a los originales de tu versión y busca
<scripten la configuración y contenidos de la base de datos. En la guía de PrestaShop hackeado tienes las consultas. - Atiende a las señales externas: clientes que te cuentan cargos raros tras comprar, o la pasarela o el banco preguntando por fraude con tarjetas que tienen en común tu tienda.
Para la vigilancia continua, las normas de la industria de tarjetas lo piden expresamente. Desde el 31 de marzo de 2025, PCI DSS 4.0 exige en sus requisitos 6.4.3 y 11.6.1 llevar inventario y autorizar los scripts de la página de pago y tener un mecanismo que avise de cambios en ella. Según el PCI Security Standards Council, los comercios que usan un formulario de pago incrustado deben poder confirmar que su web no es susceptible a ataques de scripts. Tu pasarela te dirá qué cuestionario te corresponde.
Una medida técnica que ayuda mucho es una cabecera Content-Security-Policy que solo permita cargar scripts y enviar datos a los dominios que tú decides. Empieza en modo Content-Security-Policy-Report-Only para ver qué se rompería antes de aplicarla.
Primeros pasos si sospechas
- Desactiva el método de pago afectado, o pon la tienda en mantenimiento. Cada pedido con el skimmer activo es una tarjeta más.
- Haz una copia completa del estado actual, logs incluidos, antes de limpiar. Es la prueba de qué pasó y desde cuándo.
- Avisa a tu pasarela de pago o banco adquirente: tienen procedimientos para estos casos y pueden pedirte un informe.
- Cambia las contraseñas del back-office, hosting, base de datos y de la cuenta de la pasarela.
- Limpia y cierra la entrada: quitar el código no basta si el módulo vulnerable sigue ahí. Lo tienes paso a paso en cómo recuperar una web hackeada.
- Calcula la ventana: desde cuándo estaba el skimmer y cuántos pedidos pasaron por el pago en ese tiempo. Lo necesitarás para el banco y para la notificación.
Obligaciones de notificación
Los datos de tarjeta, nombre, dirección y correo de tus clientes son datos personales. Un skimmer es, casi siempre, una brecha de datos con riesgo alto para los afectados. En España, el RGPD obliga a notificarla a la AEPD sin dilación indebida y, si es posible, en 72 horas desde que tienes constancia, y a comunicarla a los clientes afectados cuando el riesgo es alto. Lo explico paso a paso, con los formularios de la AEPD, en brecha de datos en tu tienda online: qué hacer en 72 horas.
Si quieres que lo revise yo
La limpieza de una tienda PrestaShop o WooCommerce cuesta 349 € (IVA no incluido) e incluye la revisión del checkout en busca de skimmers y formularios falsos, overrides y plantillas modificados, y orientación sobre la notificación de la brecha. Si necesitas que tenga prioridad sobre el resto de trabajos: +100 €. Para prevenirlo, el informe de seguridad de tienda (169 €) revisa el pago aunque no haya síntomas. Más en PrestaShop hackeado y seguridad WooCommerce; lo que reviso en una tienda PrestaShop para prevenirlo, en seguridad PrestaShop.
Fuentes
Preguntas frecuentes
¿Cómo sé si están robando las tarjetas en mi tienda online?
Haz una compra de prueba sin sesión iniciada y revisa con las herramientas del navegador a qué dominios se conecta la página de pago. Las señales externas típicas son clientes con cargos raros tras comprar y avisos de la pasarela o del banco.
¿Si uso una pasarela con redirección estoy a salvo?
No del todo. El skimmer no puede leer la página de la pasarela, pero puede pintar un formulario falso en tu checkout antes de la redirección. Es la variante que se usó en la campaña de 2022 contra PrestaShop.
¿Qué es Magecart?
Es el nombre que se usa para los grupos y ataques que inyectan skimmers en tiendas online. Empezó con Magento (lo que conviene vigilar en esa plataforma está en seguridad Magento), pero el mismo tipo de ataque afecta a PrestaShop, WooCommerce y cualquier otra plataforma.
¿Tengo que avisar a mis clientes?
Si los datos de tarjeta o personales han quedado expuestos, el riesgo suele ser alto y el RGPD exige comunicarlo a los afectados, además de notificar a la AEPD. Decídelo con tu asesor con el informe técnico delante.
¿Un plugin de seguridad detecta un skimmer?
A veces, si coincide con una firma conocida. Pero muchos skimmers viven en la base de datos u ofuscados en archivos legítimos y solo actúan en el pago, por eso conviene revisar el checkout de forma específica.