# Skimmers: cómo detectar si roban las tarjetas en tu tienda

> Cómo funcionan los skimmers que roban tarjetas en PrestaShop y WooCommerce, dónde se esconden, por qué el administrador no los ve y qué hacer si sospechas.

URL: https://webintacta.com/guias/robo-de-tarjetas-tienda-online
Última actualización: 2026-10-15

**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.


Por Jose Soriano (WebIntacta) · publicada el 2026-10-08

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.

## 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](https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/): 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](https://webintacta.com/guias/modulos-prestashop-vulnerables). 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.php` o `classes/PaymentModule.php`, o un **override** nuevo en `override/`.
- **Un módulo** enganchado a `displayHeader` o a los hooks del pago, a veces con un nombre que imita a uno legítimo.
- **La base de datos**: un `<script>` guardado en `ps_configuration` o 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.php` del tema** o un plugin falso, a menudo en `wp-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

1. **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.
2. **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.
3. **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](https://webintacta.com/analisis-seguridad-web-gratis) lista los scripts externos de la portada y las versiones visibles de módulos y plugins con fallos publicados.
4. **Revisa la integridad de los archivos** frente a los originales de tu versión y busca `<script` en la configuración y contenidos de la base de datos. En la guía de [PrestaShop hackeado](https://webintacta.com/guias/prestashop-hackeado-que-hacer) tienes las consultas.
5. **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](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a), 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

1. **Desactiva el método de pago afectado**, o pon la tienda en mantenimiento. Cada pedido con el skimmer activo es una tarjeta más.
2. **Haz una copia completa** del estado actual, logs incluidos, antes de limpiar. Es la prueba de qué pasó y desde cuándo.
3. **Avisa a tu pasarela de pago o banco adquirente**: tienen procedimientos para estos casos y pueden pedirte un informe.
4. **Cambia las contraseñas** del back-office, hosting, base de datos y de la cuenta de la pasarela.
5. **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](https://webintacta.com/guias/recuperar-web-hackeada).
6. **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](https://webintacta.com/guias/brecha-datos-tienda-online-rgpd).

> Esto no es asesoramiento jurídico. Para la parte legal, apóyate en tu asesor o delegado de protección de datos; yo me encargo de la parte técnica: qué datos, desde cuándo y por dónde entraron.

## 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](https://webintacta.com/prestashop-hackeado) y [seguridad WooCommerce](https://webintacta.com/seguridad-woocommerce); lo que reviso en una tienda PrestaShop para prevenirlo, en [seguridad PrestaShop](https://webintacta.com/seguridad-prestashop).

## Fuentes

- [PrestaShop: aviso de la campaña de julio de 2022](https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/).
- [Friends of Presta: avisos de seguridad de módulos](https://security.friendsofpresta.org/).
- [PCI SSC: cambios en el SAQ A y requisitos 6.4.3 y 11.6.1](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a).
- [AEPD: notificación de brechas de datos personales](https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion).

## 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](https://webintacta.com/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.

## Sobre el autor

[Jose Soriano](https://webintacta.com/quien-soy): Desarrollador fullstack especializado en PrestaShop, WordPress y WooCommerce, con el curso y el examen oficiales de PrestaShop aprobados. Desarrolla tiendas online y módulos desde 2023 y es el fundador de WebIntacta, el servicio de seguridad web con el que analiza, limpia y mantiene él mismo webs de pymes y tiendas online, en remoto desde Ibi (Alicante). Datos de WebIntacta: https://webintacta.com/quien-soy#datos