Cómo proteger tu tienda online durante el Black Friday y la campaña de Navidad

La seguridad de una tienda online en campaña no se improvisa en noviembre: se prepara desde septiembre. Las tres medidas con más impacto son inventariar y controlar los scripts de la página de pago —obligatorio desde marzo de 2025 por PCI DSS—, congelar los cambios en producción antes del pico y tener definido quién responde, y cómo, si algo falla un viernes por la noche.

Puntos clave

El Black Friday de 2026 cae el 27 de noviembre y el Cyber Monday el 30. La ventana útil de preparación empieza ahora.
El riesgo no crece solo por el volumen. Crece porque el tráfico anómalo se camufla entre el legítimo, porque se despliegan cambios de última hora y porque el equipo está saturado.
El ataque característico del sector es el web skimming (Magecart): código malicioso inyectado en la página de pago que roba los datos de tarjeta sin alterar la apariencia de la web.
Los requisitos 6.4.3 y 11.6.1 de PCI DSS son obligatorios desde el 31 de marzo de 2025. Exigen inventariar, autorizar y verificar la integridad de cada script de la página de pago, y detectar cambios no autorizados.
La medida más barata y más eficaz es organizativa: congelar los despliegues durante la campaña.

Por qué la campaña multiplica el riesgo

El comercio electrónico español cerró 2025 con una facturación superior a los 114.800 millones de euros, un 20,6 % más que el año anterior, según los datos de la Comisión Nacional de los Mercados y la Competencia publicados en julio de 2026. El cuarto trimestre —el de Black Friday, Cyber Monday y Navidad— fue el más intenso: 31.418 millones de euros, un 22 % de crecimiento interanual y más de 575 millones de transacciones.

Ese volumen explica el atractivo para el atacante, pero no explica del todo por qué la campaña es más peligrosa. Hay tres razones operativas que pesan más:

1. El ruido tapa la señal. Con el tráfico multiplicado, los picos de peticiones, los intentos de acceso fallidos y las transacciones inusuales dejan de destacar. Lo que en marzo salta como anomalía, en Black Friday parece campaña.

2. Se toca producción cuando no se debe. Descuentos que se activan a última hora, un banner nuevo, un píxel de seguimiento, un plugin de recomendaciones. Cada cambio introducido bajo presión es una oportunidad de error de configuración.

3. El equipo está al límite. El mismo puñado de personas atiende incidencias de stock, caídas de pasarela y consultas de clientes. El tiempo de reacción ante algo realmente grave se alarga justo cuando debería acortarse.

Los 6 ataques que más afectan a un ecommerce en campaña

Web skimming (Magecart): el robo de tarjetas en tu propia página de pago

Es el ataque característico del comercio electrónico. El atacante inyecta un fragmento de JavaScript en la página de pago que copia los datos de tarjeta según el cliente los teclea y los envía a un servidor externo. La compra se completa con normalidad, el cliente recibe su pedido y nadie detecta nada durante semanas.

La entrada más habitual no es tu servidor: es un proveedor externo. Un script de analítica, un chat de atención al cliente, una herramienta de test A/B o un plugin de reseñas comprometido en origen. Tú actualizas tu CMS religiosamente y el skimmer sigue ahí, porque no está en tu código.

Cómo se detecta: solo con monitorización del lado del cliente. Ni el análisis de vulnerabilidades del servidor ni el antivirus lo ven.

Bots: apropiación de cuentas y reventa automatizada

Tres usos distintos, todos habituales en campaña:

Credential stuffing. El atacante prueba de forma masiva combinaciones de usuario y contraseña filtradas en brechas ajenas. Funciona porque la gente reutiliza credenciales. Las cuentas de cliente comprometidas dan acceso a direcciones, historial y, a veces, tarjetas guardadas o saldo en monedero.
Reventa automatizada (scalping). Bots que agotan el stock de un producto con descuento en segundos para revenderlo. No es un incidente de seguridad clásico, pero destruye la campaña y la reputación.
Raspado de precios. Competidores que monitorizan tus descuentos en tiempo real para ajustarse por debajo.

Señal de alerta: picos de inicios de sesión fallidos, tasas de conversión anómalas por dirección IP, carritos creados y abandonados en milisegundos.

Phishing suplantando tu marca

En campaña se disparan las webs falsas que imitan tiendas conocidas y los correos de «problema con tu envío». El daño es doble: tus clientes pierden dinero y tu marca pierde confianza, aunque tus sistemas no hayan sido tocados.

Qué puedes hacer: vigilar registros de dominios parecidos al tuyo, configurar correctamente la autenticación del correo corporativo para dificultar la suplantación, y avisar a tus clientes por adelantado de qué comunicaciones vas a enviar y cuáles no.

Ransomware en el peor momento posible

No es casualidad que estos ataques se concentren en vísperas de festivo: el atacante busca el momento de máxima presión y mínima cobertura. Cifrar el sistema de gestión de pedidos el 27 de noviembre multiplica las probabilidades de que se pague.

Según el informe Data Breach Investigations Report (DBIR) 2026 de Verizon, publicado el 19 de mayo de 2026, el ransomware aparece en el 48 % de las brechas analizadas.

Lo que marca la diferencia: copias de seguridad aisladas de la red y con restauración probada, no solo programada.

DDoS y caídas por saturación

Un ataque de denegación de servicio en campaña no busca robar nada: busca que no puedas vender. Y a veces ni siquiera hace falta un ataque, basta con un pico legítimo mal dimensionado. Para el negocio, el resultado es idéntico.

Fraude: contracargos, tarjetas regalo y devoluciones

El fraude no técnico también se dispara: compras con tarjetas robadas que acaban en contracargo, abuso de tarjetas regalo y saldos promocionales, y fraude en devoluciones. Erosiona el margen directamente y es difícil de distinguir del comportamiento legítimo sin reglas específicas de detección.

Qué exige PCI DSS 4.0.1 a tu página de pago (y desde cuándo)

Este es el punto que más comercios tienen pendiente, y ya no es opcional.

PCI DSS es el estándar de seguridad de datos del sector de tarjetas de pago. Su versión 4.0.1, publicada en junio de 2024, incorporó una serie de requisitos con fecha de aplicación diferida. Ese plazo venció el 31 de marzo de 2025: desde entonces son plenamente exigibles en auditoría. Dos afectan directamente a cualquier tienda online:

Requisito 6.4.3 — Control de los scripts de la página de pago. Obliga a mantener un inventario documentado de todos los scripts que se ejecutan en el navegador del cliente en la página de pago, con justificación escrita de por qué está cada uno y quién lo autorizó, además de un método que confirme que no han sido manipulados. Aplica a todos los scripts, no solo a los relacionados con el pago: analítica, chat, herramientas de test.

Los métodos aceptados para verificar la integridad son la integridad de subrecursos (SRI), una política de seguridad de contenidos (CSP) bien definida o un servicio de monitorización de scripts.

Requisito 11.6.1 — Detección de cambios y manipulación. Exige un mecanismo que alerte al personal ante modificaciones no autorizadas en las cabeceras HTTP y en el contenido de las páginas de pago, con una evaluación al menos semanal.

Un matiz que ha despistado a muchos comercios. En enero de 2025, el PCI Security Standards Council retiró estos dos requisitos del cuestionario de autoevaluación SAQ A —el que usan los comercios que han externalizado por completo el procesamiento del pago— y los sustituyó por un criterio de elegibilidad: el comercio debe confirmar que su web no es susceptible a ataques basados en scripts que puedan afectar al proceso de pago. Retirar el requisito del formulario no elimina la obligación de proteger la página. Cambia cómo se demuestra, no qué hay que hacer.

La conclusión práctica: aunque uses una pasarela externa o un iframe, sigues teniendo que responder a una pregunta muy concreta —qué scripts se ejecutan en tu checkout, quién los puso y si siguen siendo necesarios.

Calendario de preparación: qué hacer y cuándo

Con el Black Friday el 27 de noviembre de 2026 como referencia, esta es la secuencia que mejor funciona.

8 semanas antes: auditoría y deuda técnica

Revisa tu exposición externa. Qué tienes publicado en internet: entornos de preproducción, paneles de administración accesibles, subdominios olvidados. Una evaluación del estado real de tu ciberseguridad ordena esto en semanas, no en meses.
Parchea la plataforma y las extensiones. Magento, WooCommerce, PrestaShop y sus plugins concentran buena parte de los incidentes. Retira las extensiones que no uses: cada una es código de terceros ejecutándose en tu tienda.
Inventaría los scripts del checkout. El ejercicio del requisito 6.4.3. Suele aparecer alguna sorpresa: herramientas instaladas por marketing hace dos años que nadie recuerda.
Revisa accesos. Cuentas de empleados que ya no están, credenciales compartidas de agencias, accesos de proveedores sin caducidad. Con doble factor obligatorio en todo panel de administración, sin excepciones. Nuestra guía sobre política de contraseñas detalla los criterios actuales.
Considera una prueba de intrusión. Es el momento: da margen para corregir lo que aparezca. Hacerla en noviembre solo sirve para tener una lista de problemas que no puedes tocar. Nuestro servicio de pentesting recurrente está pensado para este tipo de ciclos.

4 semanas antes: resistencia y planes

Prueba de carga con un escenario realista de pico, incluyendo la pasarela de pago.
Verifica las copias de seguridad restaurando de verdad. Una copia no probada no es una copia. Al menos una debe estar aislada de la red y ser inmutable.
Escribe el plan de respuesta a incidentes en una página. Quién decide, quién comunica, a qué teléfono se llama a las tres de la madrugada, en qué casos se corta el servicio y en cuáles se contiene.
Refuerza la protección frente a bots en inicio de sesión, registro y aplicación de cupones.
Forma al equipo con el foco puesto en la campaña: correos de falsos proveedores, urgencias de dirección, cambios de cuenta bancaria. La concienciación continua con simulaciones es lo que sostiene esto durante todo el año, no una sesión suelta en octubre.

1 semana antes: congelar y cubrir

Congelación de cambios. Solo entran correcciones críticas, con aprobación explícita y capacidad de revertir.
Guardias definidas por escrito, con nombres y turnos, incluidos festivos.
Contactos de emergencia verificados: proveedor de hosting, pasarela de pago, asesoría legal, servicio de respuesta a incidentes. Verificados quiere decir que alguien ha llamado y ha contestado.

Durante la campaña: qué vigilar cada día

Alertas de cambios en las páginas de pago y en los scripts.
Intentos de acceso fallidos y accesos administrativos fuera de horario o desde ubicaciones inhabituales.
Picos de tráfico con patrón no humano.
Transacciones rechazadas y ratios de contracargo.
Disponibilidad y tiempos de respuesta.

Este es el punto donde la mayoría de las empresas medianas se queda corta: la vigilancia tiene que ser continua, y los ataques se concentran precisamente en las noches y los fines de semana. Es la lógica de un SOC gestionado 24×7, que cubre las horas en las que no hay nadie mirando.

Después: cerrar bien

Revoca los accesos temporales creados para la campaña. Es la tarea que más se olvida y la que deja puertas abiertas hasta el año siguiente.
Levanta la congelación de forma ordenada, con despliegues escalonados.
Revisa qué alertas se dispararon, cuáles eran ruido y cuánto se tardó en responder.
Documenta las lecciones aprendidas mientras están frescas. En febrero ya nadie se acuerda.

La regla que más incidentes evita: congela los cambios

Si solo puedes aplicar una medida de toda esta guía, aplica esta.

La mayoría de las caídas y de los fallos de configuración en campaña no los provoca un atacante: los provoca un despliegue de última hora hecho con prisa, sin revisión y sin plan de vuelta atrás. Una promoción que había que activar «ya», un descuento mal configurado, un plugin instalado a las once de la noche.

Congelar los cambios significa acordar, por escrito y con dirección, que entre una fecha y otra no se toca producción salvo corrección crítica. Es gratis, no requiere tecnología y reduce de forma inmediata la superficie de error. La resistencia que genera es siempre comercial, nunca técnica, y por eso conviene pactarlo en septiembre y no la semana antes.

Qué hacer si sufres un incidente en plena campaña

La decisión difícil llega primero: ¿cortar o contener? Cortar el servicio en Black Friday tiene un coste evidente. Seguir vendiendo mientras un skimmer captura tarjetas tiene un coste mayor, y además legal. La regla práctica: si hay indicios de que se están comprometiendo datos de pago o personales, se contiene la parte afectada aunque duela.

Segundo, evidencias antes que limpieza. El impulso natural es reinstalar y seguir. Sin registros ni copia del sistema comprometido, después no podrás saber qué se llevaron ni durante cuánto tiempo, que es justo lo que te va a preguntar la autoridad de control.

Tercero, obligaciones legales. Si hay datos personales afectados, el Reglamento General de Protección de Datos exige notificar a la Agencia Española de Protección de Datos en un plazo de 72 horas desde que se tiene conocimiento de la brecha, y comunicar a los afectados cuando el riesgo para sus derechos sea alto. Si tu organización está sujeta a NIS2, los plazos de alerta temprana son aún más cortos.

Cuarto, comunicación. Decidir de antemano quién habla con clientes, con la pasarela de pago y con los medios evita el silencio de tres días que multiplica el daño reputacional.

«Complementar la capacitación con sistemas de detección y respuesta 24/7 puede marcar la diferencia entre una interrupción mínima y un colapso total», recuerda David López, director de operaciones de Factum.

Preguntas frecuentes

¿Cuándo cae el Black Friday de 2026 y cuándo hay que empezar a preparar la seguridad? El Black Friday de 2026 es el 27 de noviembre y el Cyber Monday el 30. La preparación efectiva empieza unas ocho semanas antes, a principios de octubre, porque las correcciones que salen de una auditoría necesitan tiempo de implantación. En noviembre ya solo da tiempo a vigilar y a no tocar nada.

¿Qué es un ataque Magecart o web skimming? Es la inyección de código JavaScript malicioso en la página de pago de una tienda online para copiar los datos de tarjeta mientras el cliente los introduce. La compra se completa con normalidad y la web no cambia de aspecto, por lo que suele pasar semanas sin detectarse. Entra con frecuencia a través de un proveedor externo.

¿Qué exige PCI DSS a mi tienda online desde 2025? Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 son obligatorios desde el 31 de marzo de 2025. Exigen inventariar y autorizar todos los scripts de la página de pago, verificar su integridad y detectar cambios no autorizados en esas páginas, con revisión al menos semanal.

Si uso una pasarela de pago externa, ¿estoy cubierto? Reduce mucho la exposición, porque los datos de tarjeta no pasan por tus sistemas, pero no te exime. Desde 2025, los comercios que validan con SAQ A deben confirmar que su web no es susceptible a ataques basados en scripts. Sigues siendo responsable de lo que se ejecuta en tu checkout.

¿Un WAF y un CDN protegen mi tienda en campaña? Ayudan con la disponibilidad, con los picos de tráfico y con los ataques automatizados conocidos, pero no cubren el web skimming introducido a través de un proveedor legítimo ni el fraude con credenciales válidas. Son una capa, no una solución completa.

¿Qué hago si detecto un incidente en pleno Black Friday? Contén la parte afectada si hay indicios de compromiso de datos de pago o personales, conserva las evidencias antes de limpiar nada, y activa el plan de notificación. Con datos personales afectados, el RGPD exige comunicarlo a la Agencia Española de Protección de Datos en 72 horas.

¿Sabes qué ve un atacante de tu tienda antes de que empiece la campaña? El informe de cibervigilancia de Cylum revisa tu exposición externa y te devuelve un punto de partida concreto, a tiempo para corregir lo que aparezca.

Fuentes

Comisión Nacional de los Mercados y la Competencia (CNMC), datos de comercio electrónico del cuarto trimestre y del conjunto de 2025, publicados el 3 de julio de 2026. https://www.cnmc.es/prensa/comercio-electronico-20260703
PCI Security Standards Council, PCI DSS v4.0.1 (junio de 2024) y guía sobre los requisitos de comercio electrónico efectivos tras el 31 de marzo de 2025, incluidos 6.4.3 y 11.6.1. https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-guidance-for-pci-dss-e-commerce-requirements-effective-after-31-march-2025
PCI Security Standards Council, actualización del cuestionario SAQ A de enero de 2025 y su nuevo criterio de elegibilidad.
Verizon, 2026 Data Breach Investigations Report, publicado el 19 de mayo de 2026. [VERIFICAR: enlazar a la página oficial del informe antes de publicar]
Reglamento (UE) 2016/679 (RGPD), artículos 33 y 34, sobre notificación de brechas de seguridad.