PCI Monitor
Biblioteca de seguridad
Ningún tema coincide con “”. Pruebe con una palabra más corta o con una de estas: skimming web, CSP, 6.4.3, SRI, cabeceras de seguridad. O empiece por una guía popular:
Amenazas
Cómo roban datos de tarjetas en el navegador y qué muestran los casos reales.
¿Qué es el skimming web? Magecart y formjacking
El skimming web (Magecart, formjacking, e-skimming) oculta JavaScript en páginas de pago que copia los datos de la tarjeta mientras se escriben.
El skimming web es el robo de datos de tarjetas de pago mediante JavaScript malicioso que se ejecuta en el navegador del comprador, en una página de compra o de pago. El script copia lo que el cliente escribe y se lo envía al atacante, mientras el pago real se completa con normalidad, de modo que nadie lo nota. También se conoce como e-skimming, formjacking o ataques tipo Magecart, y es la amenaza que los requisitos 6.4.3 y 11.6.1 de PCI DSS buscan atender.
Puntos clave
- El skimming web es JavaScript malicioso en una página de pago que copia datos de tarjetas en el navegador; Magecart, e-skimming y formjacking son nombres de la misma familia de ataques.
- La compra se completa con normalidad, por eso un skimmer puede funcionar mucho tiempo sin ser notado.
- HTTPS y los firewalls del servidor no lo detienen, porque el robo ocurre en el navegador del cliente.
- Las redirecciones y los iframes reducen su exposición, pero no eliminan la necesidad de proteger la página que los rodea.
- La defensa práctica es por capas: menos scripts, un inventario con aprobaciones, una CSP restrictiva, controles de integridad, parches y detección de cambios.
Preguntas frecuentes
- ¿Qué es el skimming web?
- El skimming web es el robo de datos de tarjetas de pago mediante JavaScript malicioso que se ejecuta en una página de compra o de pago y copia los datos que los clientes escriben en el formulario. El atacante recibe los datos mientras el pago real continúa con normalidad.
- ¿Magecart es un virus?
- No. Magecart no es un programa ni un grupo único. Es un nombre genérico que usan los investigadores para muchos grupos y campañas criminales que inyectan en sitios web JavaScript que roba tarjetas.
- ¿HTTPS protege contra el skimming web?
- No. HTTPS protege los datos mientras viajan entre el navegador y su servidor. Un skimmer lee los datos dentro del navegador, antes de enviarlos, de modo que un certificado válido no lo impide.
- Si uso una página de pago alojada o un iframe, ¿mi sitio puede sufrir skimming?
- El riesgo es menor, pero no es cero. Un atacante que controle la página que rodea una redirección o un iframe podría reemplazar el formulario de pago o enviar a los clientes a otro lugar. PCI DSS 6.4.3 y 11.6.1 lo tienen en cuenta, y su adquirente o su evaluador decide cómo se aplican a usted.
- ¿Cómo me enteraría de que mi sitio tiene un skimmer?
- Rara vez mirando la página. Las organizaciones encuentran los skimmers mediante un monitoreo que compara los scripts y las cabeceras que recibe un navegador con una línea base aprobada, mediante avisos de bancos emisores o marcas de tarjetas, o mediante investigación de seguridad. Por eso la detección de cambios forma parte de la respuesta de PCI DSS.
Leer la guía completa: ¿Qué es el skimming web? Magecart y formjacking
Riesgo de JavaScript de terceros: cadena de suministro
Los scripts de terceros en páginas de pago (gestores de etiquetas, analítica, chats) son un riesgo de cadena de suministro. Cómo ocurre y cómo gestionarlo.
Cada script de terceros en una página de pago se ejecuta con el mismo acceso que su propio código: puede leer el formulario, cambiar la página y enviar datos a cualquier lugar. Si la empresa que sirve ese script sufre una intrusión, vende su dominio o simplemente publica una actualización defectuosa, los navegadores de sus clientes ejecutan el código del atacante. Es un riesgo de cadena de suministro de software, y es la principal vía por la que el robo de tarjetas del lado del cliente llega a comercios bien defendidos.
Puntos clave
- Un script de terceros tiene el mismo poder que su propio código; el navegador no lo limita a las tareas que usted tenía en mente.
- Las vías de compromiso incluyen un proveedor vulnerado, un dominio que cambia o vence, cadenas de scripts que cargan otros scripts y contenido que varía según el visitante.
- El caso de polyfill.io en 2024 mostró que una dirección de confianza puede empezar a servir código dañino sin que cambie nada en los sitios que la usan.
- Cargue menos scripts de terceros en las páginas de pago, mantenga un inventario con aprobaciones y fije o restrinja los que queden.
- La aprobación en el momento de añadir un script no basta; vigile lo que realmente se entrega.
Preguntas frecuentes
- ¿Qué es un ataque a la cadena de suministro de JavaScript?
- Es un ataque en el que el atacante compromete un script, una biblioteca o un servicio que cargan muchos sitios web, de modo que el código malicioso llega a todos esos sitios a la vez sin que el atacante tenga que entrar en cada uno.
- ¿La Integridad de Subrecursos (SRI) resuelve el riesgo de los scripts de terceros?
- Ayuda con archivos estáticos desde una dirección fija, porque el navegador bloquea un archivo que ya no coincide con su hash. No sirve con scripts que se generan para cada visitante o se actualizan con frecuencia, ni con scripts cargados por otros scripts. Vea el artículo sobre Integridad de Subrecursos.
- ¿Es más seguro alojar yo mismo una copia de la biblioteca?
- Elimina el riesgo de que el servidor del proveedor cambie el archivo a sus espaldas, pero usted pasa a ser responsable de actualizar la copia y de cualquier vulnerabilidad que tenga. Funciona mejor junto con un proceso de aprobación y actualización.
- ¿Deben las páginas de pago cargar scripts de analítica y publicidad?
- Cada uno amplía la superficie de ataque, y muchas organizaciones deciden no cargarlos en la página de pago. Si los carga, cada uno necesita un motivo por escrito, una aprobación y monitoreo. PCI DSS 6.4.3 se aplica a todos los scripts de la página de pago.
Leer la guía completa: Riesgo de JavaScript de terceros: cadena de suministro
Incidentes de robo de tarjetas en el navegador: lecciones
Qué enseñan los incidentes de skimming web de 2018 en British Airways, Ticketmaster y Newegg sobre scripts de terceros, detección y reguladores.
Tres incidentes de 2018, en British Airways, Ticketmaster UK y Newegg, muestran cómo se roban datos de tarjetas de las páginas de pago mediante JavaScript inyectado o alterado. En dos de ellos la Oficina del Comisionado de Información del Reino Unido (ICO) impuso después sanciones; en el tercero, investigadores externos encontraron el skimmer. Este artículo se limita a lo que han publicado las decisiones oficiales y los investigadores originales, y extrae las lecciones prácticas.
Puntos clave
- British Airways, Ticketmaster UK y Newegg (todos en 2018) muestran skimming mediante JavaScript del propio sitio, un chatbot de terceros y un script inyectado corto.
- La ICO multó a British Airways con 20 millones de libras (16 de octubre de 2020) y a Ticketmaster UK con 1,25 millones de libras (13 de noviembre de 2020).
- Los skimmers funcionaron durante semanas y en varios casos los encontraron terceros externos.
- Las lecciones prácticas: monitoree la página tal como la recibe el navegador, justifique cada script, restrinja los orígenes de scripts y los destinos de los datos, y detecte los cambios con rapidez.
Preguntas frecuentes
- ¿Cuánto multaron a British Airways por su incidente de skimming web de 2018?
- La ICO impuso a British Airways una multa de 20 millones de libras en un aviso de sanción fechado el 16 de octubre de 2020. La ICO había anunciado en julio de 2019 la intención de multar con 183,39 millones de libras; el importe final fue menor tras considerar las alegaciones, los factores atenuantes y el efecto de la Covid-19 en la industria aérea.
- ¿Qué causó la brecha de Ticketmaster UK?
- Según las conclusiones de la ICO, código malicioso en un chatbot suministrado por un tercero e incluido en la página de pago de Ticketmaster capturó los datos de tarjeta de los clientes. La ICO multó a Ticketmaster UK con 1,25 millones de libras; Ticketmaster ha cuestionado aspectos de la decisión.
- ¿Cuánto tiempo estuvo activo el skimmer de Newegg?
- Los investigadores informaron de que los datos de tarjeta introducidos en el pago quedaron expuestos del 14 de agosto al 18 de septiembre de 2018, unas cinco semanas. Esto proviene del análisis de los investigadores recogido en cobertura secundaria.
- ¿Estos incidentes dieron lugar a PCI DSS 6.4.3 y 11.6.1?
- El PCI SSC dice que los requisitos buscan reducir el e-skimming, del que estos incidentes son ejemplos, pero no nombra incidentes concretos como causa. Considérelos un contexto y no un motivo documentado.
Leer la guía completa: Incidentes de robo de tarjetas en el navegador: lecciones
XSS, manipulación del DOM y código skimmer inyectado
Cómo llega código malicioso a una página de pago: XSS, complementos y bibliotecas vulnerables, credenciales robadas y terceros comprometidos.
Un skimmer primero tiene que llegar a la página de pago. Las vías habituales son fallos de cross-site scripting (XSS), complementos o bibliotecas vulnerables, credenciales de administrador o de despliegue robadas, y terceros comprometidos. Una vez que un script se ejecuta en la página, también puede manipular el Modelo de Objetos del Documento (DOM), por ejemplo añadiendo campos o reemplazando un formulario de pago. Conocer las vías de entrada muestra dónde concentrar la prevención y la detección.
Puntos clave
- El XSS permite a un atacante ejecutar un script en su página de pago sin ningún acceso a sus servidores.
- Otras vías de entrada: complementos y bibliotecas vulnerables, credenciales robadas, terceros comprometidos y almacenamiento con permisos de escritura indebidos.
- La manipulación del DOM permite que un script inyectado añada campos, superponga formularios y copie datos, incluso cuando el HTML de su servidor está limpio.
- Combine programación segura, una Política de Seguridad de Contenido estricta, parches, un control de acceso sólido y monitoreo de lo que reciben los navegadores.
Preguntas frecuentes
- ¿Cuál es la diferencia entre XSS y un skimmer web?
- El XSS es un tipo de fallo que permite a un atacante ejecutar un script en una página. Un skimmer es el propio script malicioso, cuya tarea es copiar datos de tarjetas. El XSS es una de las formas en que puede entregarse un skimmer.
- ¿Qué es la manipulación del DOM?
- Es cambiar la estructura viva de una página web en el navegador, por ejemplo añadiendo campos de formulario, superponiendo un formulario falso o quitando un elemento. Cualquier script que se ejecute en la página puede hacerlo.
- ¿Una Política de Seguridad de Contenido puede detener el XSS?
- Una política bien construida puede bloquear scripts en línea inyectados y scripts de orígenes no aprobados, lo que hace fracasar muchos ataques de XSS. Es una segunda línea de defensa sólida, no un sustituto de corregir el fallo.
- ¿Basta el monitoreo de archivos del servidor para encontrar un skimmer inyectado?
- No por sí solo. Ayuda cuando el atacante cambió archivos en su servidor, pero no ve los cambios hechos por el script de un tercero o por un complemento que se ejecuta en el navegador. Revisar lo que recibe el navegador cubre esa brecha.
Leer la guía completa: XSS, manipulación del DOM y código skimmer inyectado
Estándares (PCI DSS)
Qué piden el 6.4.3 y el 11.6.1, por qué existen y cómo se aplican a su SAQ.
Por qué existen los requisitos PCI DSS 6.4.3 y 11.6.1
El PCI SSC añadió 6.4.3 y 11.6.1 a PCI DSS v4.0 contra el e-skimming. La amenaza, la cronología, v4.0.1 y qué fue obligatorio el 31 de marzo de 2025.
Los requisitos 6.4.3 y 11.6.1 de PCI DSS se introdujeron en PCI DSS v4.0 (publicado el 31 de marzo de 2022) para reducir el e-skimming: el robo de datos de tarjetas mediante scripts maliciosos que se ejecutan en el navegador del comprador. Ambos empezaron como requisitos con fecha futura y pasaron a ser obligatorios el 31 de marzo de 2025. El 6.4.3 trata de gestionar los scripts de las páginas de pago; el 11.6.1, de detectar cambios no autorizados en esas páginas y en sus cabeceras HTTP.
Puntos clave
- Los requisitos 6.4.3 y 11.6.1 se añadieron en PCI DSS v4.0 (31 de marzo de 2022) para reducir el e-skimming en el navegador del comprador.
- Ambos tenían fecha futura y pasaron a ser obligatorios el 31 de marzo de 2025; la v4.0.1 (11 de junio de 2024) es la versión vigente y añadió notas aclaratorias.
- El 6.4.3 gestiona qué scripts se ejecutan en las páginas de pago; el 11.6.1 detecta cambios no autorizados en esas páginas y en sus cabeceras HTTP.
- El suplemento informativo de marzo de 2025 es una guía, no un requisito.
- Cómo se aplican los requisitos a usted depende de cómo acepte pagos y de lo que decidan su adquirente y su evaluador.
Preguntas frecuentes
- ¿Cuándo pasaron a ser obligatorios PCI DSS 6.4.3 y 11.6.1?
- El 31 de marzo de 2025. Se publicaron como requisitos con fecha futura en PCI DSS v4.0 el 31 de marzo de 2022 y se trataron como mejores prácticas hasta esa fecha.
- ¿Qué versión de PCI DSS se aplica hoy?
- PCI DSS v4.0.1, publicada el 11 de junio de 2024. La versión 3.2.1 se retiró el 31 de marzo de 2024 y la v4.0 el 31 de diciembre de 2024. Consulte la biblioteca de documentos del PCI SSC por si hay una versión posterior.
- ¿Qué es el suplemento informativo del PCI SSC sobre e-skimming?
- Es un documento de orientación publicado en marzo de 2025, titulado Payment Page Security and Preventing E-Skimming: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1. Ofrece estrategias prácticas para comercios y proveedores de servicios de terceros, y no sustituye ni añade nada a los requisitos.
- ¿Se aplican 6.4.3 y 11.6.1 si uso una página de pago alojada o un iframe?
- Pueden aplicarse. PCI DSS v4.0.1 señala que también se aplican a una página web que incluye el formulario incrustado de un proveedor de pagos. Para los comercios elegibles del SAQ A la validación funciona de otra manera. Confirme con su adquirente o evaluador cómo se aplica a usted.
Leer la guía completa: Por qué existen los requisitos PCI DSS 6.4.3 y 11.6.1
PCI DSS 6.4.3 explicado: scripts de la página de pago
PCI DSS 6.4.3 exige autorizar cada script de la página de pago, asegurar su integridad y inventariarlo con justificación escrita. Qué significa.
El requisito 6.4.3 de PCI DSS establece que cada script que se carga y se ejecuta en el navegador del consumidor en una página de pago debe gestionarse de tres maneras: un método confirma que el script está autorizado, un método asegura su integridad y un inventario registra cada script con una justificación comercial o técnica escrita. Se aplica tanto a sus propios scripts como a los de terceros, y es obligatorio desde el 31 de marzo de 2025.
Puntos clave
- El requisito 6.4.3 tiene tres partes: autorizar cada script, asegurar la integridad de cada script y mantener un inventario con una justificación escrita.
- Abarca todo script que se ejecuta en el navegador del consumidor en la página de pago, incluidos los propios y los cargados por gestores de etiquetas.
- Pasó a ser obligatorio el 31 de marzo de 2025.
- El estándar deja el método a su elección; combinar técnicas suele cubrir más casos que cualquiera por separado.
- La evidencia debe mostrar un proceso vivo: un inventario actual que coincide con la realidad, aprobaciones y gestión de cambios.
Preguntas frecuentes
- ¿El 6.4.3 se aplica solo a scripts de terceros?
- No. Abarca todos los scripts de la página de pago que se cargan y se ejecutan en el navegador del consumidor, sean suyos, los aloje usted o los cargue de un tercero.
- ¿Una Política de Seguridad de Contenido cumple el 6.4.3?
- Una CSP puede ser una parte sólida del método de autorización porque hace cumplir qué orígenes pueden ejecutarse. Por sí sola no asegura que un archivo permitido no haya sido alterado, por lo que suele combinarse con medidas de integridad. Su evaluador decide si su combinación cumple el requisito.
- ¿Qué cuenta como justificación escrita?
- Una breve declaración de la razón comercial o técnica por la que el script es necesario en esa página de pago, lo bastante específica como para que un revisor pueda juzgar si sigue siendo necesario. «Analítica» es más débil que nombrar qué se mide y por qué debe ejecutarse en el paso de pago.
- ¿Se aplica el 6.4.3 si uso el iframe de un proveedor de pagos?
- PCI DSS v4.0.1 dice que el requisito también se aplica a los scripts de una página web que incluye el formulario incrustado de un proveedor, mientras que los comercios elegibles del SAQ A cumplen en su lugar un criterio de elegibilidad relacionado. Consulte a su adquirente o evaluador.
Leer la guía completa: PCI DSS 6.4.3 explicado: scripts de la página de pago
PCI DSS 11.6.1 explicado: detección de cambios
PCI DSS 11.6.1 exige alertas ante cambios no autorizados en el contenido y las cabeceras HTTP de la página de pago, tal como las recibe el navegador.
El requisito 11.6.1 de PCI DSS exige un mecanismo de detección de cambios y de manipulación que avise al personal de toda modificación no autorizada de las cabeceras HTTP y del contenido de las páginas de pago tal como las recibe el navegador del consumidor. Debe evaluar las cabeceras y las páginas y ejecutarse al menos una vez cada siete días, o con la frecuencia que fije un análisis de riesgos específico conforme al requisito 12.3.1. Es obligatorio desde el 31 de marzo de 2025.
Puntos clave
- El requisito 11.6.1 exige un mecanismo que avise al personal de cambios no autorizados en el contenido y las cabeceras HTTP de la página de pago.
- Debe evaluar lo que recibe el navegador del consumidor, no solo su código fuente o su servidor de origen.
- Se ejecuta al menos una vez cada siete días, o con la frecuencia de un análisis de riesgos específico documentado (12.3.1).
- El estándar no nombra ninguna herramienta; esté preparado para explicar cómo su enfoque cumple la intención.
- Es obligatorio desde el 31 de marzo de 2025; conserve evidencia de ejecuciones, alertas y decisiones.
Preguntas frecuentes
- ¿Con qué frecuencia debe ejecutarse el mecanismo del 11.6.1?
- Al menos una vez cada siete días, o periódicamente con la frecuencia definida en su análisis de riesgos específico realizado conforme al requisito 12.3.1. Un intervalo mayor necesita ese análisis documentado detrás.
- ¿Basta con monitorear mi repositorio de código para el 11.6.1?
- No. El requisito trata de las cabeceras y las páginas de pago tal como las recibe el navegador del consumidor. Las revisiones del repositorio no muestran lo que añade un gestor de etiquetas, una CDN o un script de terceros en la entrega o en tiempo de ejecución.
- ¿Qué cuenta como un cambio no autorizado?
- Un cambio que nadie con facultad para decidir aprobó: un script nuevo o eliminado, contenido de un script alterado, o una cabecera de seguridad debilitada o eliminada. Por eso los registros de aprobación del requisito 6.4.3 y las alertas del 11.6.1 funcionan juntos.
- ¿Se aplica el 11.6.1 si uso el iframe de un proveedor de pagos?
- PCI DSS v4.0.1 dice que también se aplica a una página web que incluye el formulario de pago incrustado de un proveedor, mientras que los comercios elegibles del SAQ A cumplen en su lugar un criterio de elegibilidad relacionado. Consulte a su adquirente o evaluador.
Leer la guía completa: PCI DSS 11.6.1 explicado: detección de cambios
PCI DSS 11.6.1: evidencia que debe mostrar al evaluador
Qué preparar para PCI DSS 11.6.1: el mecanismo, las páginas de pago que cubre, registros de ejecución al menos cada 7 días, alertas y decisiones.
Para PCI DSS 11.6.1 debe demostrar a un evaluador que existe un mecanismo de detección de cambios y de manipulación, que cubre sus páginas de pago y sus cabeceras HTTP tal como las recibe el navegador del consumidor, que se ejecuta al menos cada siete días (o con la frecuencia fijada en su análisis de riesgos específico) y que las personas reciben alertas y actúan. En la práctica son seis cosas: una descripción del mecanismo, la lista de páginas que cubre, la prueba de lo que evalúa, un historial fechado de ejecuciones, un registro de las alertas y de las decisiones tomadas, y el análisis de riesgos si no lo ejecuta semanalmente.
Puntos clave
- Organice la evidencia del 11.6.1 en seis elementos: el mecanismo, las páginas que cubre, lo que evalúa, el historial de ejecuciones, las alertas con sus decisiones y el análisis de riesgos si no es semanal.
- El requisito trata de las cabeceras y de las páginas de pago tal como las recibe el navegador del consumidor; demuestre que su comprobación ve lo que recibe un navegador.
- Un historial de resultados fechados importa tanto como la herramienta; consérvelo durante todo el período de la evaluación.
- Designe quién recibe las alertas y registre lo que decidió ante cada cambio.
- Su evaluador decide qué es suficiente; confirme los detalles con él desde el principio.
Preguntas frecuentes
- ¿Qué evidencia necesito para PCI DSS 11.6.1?
- Una descripción del mecanismo de detección de cambios y de manipulación, las páginas de pago que cubre, la prueba de que evalúa las cabeceras HTTP y el contenido de la página tal como los recibe el navegador del consumidor, resultados fechados de ejecuciones al menos cada siete días (o con la frecuencia de su análisis de riesgos específico) y un registro de las alertas y de las decisiones tomadas.
- ¿Basta una captura de pantalla de mi herramienta de monitorización?
- Normalmente no por sí sola. Una captura muestra un solo momento; el requisito trata de un mecanismo que se ejecuta con una periodicidad y avisa a las personas. Conserve resultados exportables y fechados y los registros de alertas, y pregunte a su evaluador qué formato acepta.
- ¿Y si no ejecuto la comprobación semanalmente?
- El requisito admite otra frecuencia solo si la fija un análisis de riesgos específico realizado conforme al requisito 12.3.1. Conserve ese análisis y su revisión junto con el resto de la evidencia.
- ¿Debe la evidencia incluir páginas detrás de un inicio de sesión?
- Si una página de pago forma parte de su flujo de pago, está en el alcance se acceda a ella como se acceda. Demuestre que su mecanismo evalúa también esas páginas y no solo las públicas.
Leer la guía completa: PCI DSS 11.6.1: evidencia que debe mostrar al evaluador
6.4.3 y 11.6.1 para SAQ A, SAQ A-EP y SAQ D
Cómo se aplican PCI DSS 6.4.3 y 11.6.1 a comercios SAQ A, SAQ A-EP y SAQ D, y el cambio del SAQ A en 2025. Confirme siempre con su adquirente.
El SAQ que usted completa, y cómo acepta pagos (redirección, iframe o envío directo), cambia la forma en que el 6.4.3 y el 11.6.1 le alcanzan. A principios de 2025 el PCI SSC eliminó ambos requisitos del SAQ A y añadió un criterio de elegibilidad según el cual el comercio ha confirmado que su sitio no es susceptible a ataques de scripts; siguen en el SAQ A-EP y en el SAQ D. Las reglas se revisan de vez en cuando, así que confirme con su adquirente o evaluador qué se le aplica.
Puntos clave
- Cómo le alcanzan el 6.4.3 y el 11.6.1 depende de si redirige, incrusta un iframe o envía los datos de la tarjeta directamente, y del SAQ que complete.
- El SAQ A ya no lista el 6.4.3, el 11.6.1 ni el 12.3.1, pero exige haber confirmado que su sitio no es susceptible a ataques de scripts; la FAQ 1588 explica cómo, para los sitios que incrustan un formulario de pago.
- Los requisitos siguen en el SAQ A-EP y en el SAQ D.
- La FAQ 1331 (revisada en agosto de 2026) advierte contra usar los criterios de los SAQ para decidir la aplicabilidad en un Informe de Cumplimiento sin el acuerdo de su adquirente.
- Confirme siempre con su adquirente o evaluador; estos documentos se revisan con el tiempo.
Preguntas frecuentes
- ¿Los comercios SAQ A deben cumplir el 6.4.3 y el 11.6.1?
- Ya no figuran como requisitos en el SAQ A. En su lugar, el SAQ A tiene un criterio de elegibilidad según el cual el comercio ha confirmado que su sitio no es susceptible a ataques de scripts. Para los sitios que incrustan un formulario de pago, la FAQ 1588 dice que esto puede cumplirse con técnicas como las del 6.4.3 y el 11.6.1, o con confirmación escrita del proveedor de pagos que cumple. Confirme con su adquirente.
- ¿Se aplica el criterio de scripts del SAQ A si redirijo a los clientes a una página de pago alojada?
- Según la FAQ 1588, no: el criterio se aplica a los sitios que incrustan una página o un formulario de pago de un tercero, y las redirecciones quedan excluidas.
- ¿Los comercios SAQ A-EP necesitan el 6.4.3 y el 11.6.1?
- Sí. Los requisitos siguen en el SAQ A-EP, porque la página propia del comercio influye en cómo llegan los datos de la tarjeta al proveedor de pagos.
- ¿Quién decide qué SAQ completo?
- Su adquirente o las marcas de pago, que son las entidades aceptantes del cumplimiento, junto con su evaluador si recurre a uno. El PCI SSC publica el estándar y los cuestionarios, pero no hace cumplir la normativa.
Leer la guía completa: 6.4.3 y 11.6.1 para SAQ A, SAQ A-EP y SAQ D
Lista de verificación PCI DSS de seguridad en el navegador
Lista práctica de seguridad del lado del cliente en PCI DSS: alcance de la página de pago, 6.4.3, 11.6.1, 12.3.1, controles 6.x afines y proveedores 12.8.
La seguridad del lado del cliente en PCI DSS se reduce a una lista corta de preguntas: qué páginas son páginas de pago, qué scripts se ejecutan en ellas y quién aprobó cada uno, cómo se asegura su integridad, cómo se detectaría y atendería un cambio no autorizado y cómo se gestiona a los terceros implicados. Esta lista agrupa esas preguntas en torno a los requisitos 6.4.3, 11.6.1, 12.3.1 y 12.8, con los controles afines que los respaldan. Úsela para preparar una conversación con su evaluador, no como sustituto del estándar.
Puntos clave
- Empiece por el alcance: sepa qué páginas son páginas de pago y cómo acepta pagos cada una.
- El requisito 6.4.3 pide autorización, aseguramiento de la integridad y un inventario con justificación escrita para cada script de la página de pago.
- El requisito 11.6.1 pide alertas ante cambios no autorizados en el contenido y las cabeceras de la página de pago tal como las recibe el navegador, al menos cada siete días o según su análisis de riesgos.
- Los proveedores de servicios de terceros caen bajo el 12.8, y la preparación ante incidentes bajo el 12.10.
- Conserve evidencia a lo largo del tiempo: debe mostrar un proceso vivo, no un ejercicio único.
Preguntas frecuentes
- ¿Cuáles son los requisitos de PCI DSS para la seguridad de la página de pago?
- Los dos requisitos dirigidos directamente a los scripts de la página de pago son el 6.4.3, que trata de autorizar, asegurar la integridad e inventariar los scripts, y el 11.6.1, que trata de detectar cambios no autorizados en las páginas de pago y en las cabeceras HTTP. Los controles afines incluyen el 6.4.2, el 6.3.2, el 12.3.1 y el 12.8.
- ¿Basta esta lista para aprobar una evaluación?
- No. Es una ayuda de preparación. Su evaluador o su adquirente decide qué se le aplica y qué evidencia es suficiente, y el cumplimiento depende de todo su programa.
- ¿Con qué frecuencia debe revisarse la lista?
- Trate el inventario de scripts y los resultados de detección como continuos, revise el análisis de riesgos específico al menos cada doce meses y vuelva a examinar el alcance cada vez que cambie cómo acepta pagos.
Leer la guía completa: Lista de verificación PCI DSS de seguridad en el navegador
Defensas
Cabeceras de seguridad, Política de Seguridad de Contenido, Integridad de Subrecursos, inventarios y detección.
Cabeceras de seguridad HTTP para páginas de pago
CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, nosniff y Cache-Control: no-store en páginas de pago y la manipulación de cabeceras.
Las cabeceras de seguridad HTTP son instrucciones que su servidor envía con cada página y que indican al navegador cómo tratarla: en qué scripts confiar, si usar solo HTTPS, quién puede enmarcar la página, qué compartir con otros sitios y qué almacenar. Para una página de pago las más importantes son Content-Security-Policy, Strict-Transport-Security, la protección contra marcos, Referrer-Policy, Permissions-Policy, X-Content-Type-Options y Cache-Control. PCI DSS 11.6.1 pide que se le avise cuando las cabeceras cambian sin autorización, porque debilitar una cabecera es un paso habitual en un ataque.
Puntos clave
- Las cabeceras de seguridad activan protecciones del navegador; es barato enviarlas y son eficaces si están bien configuradas.
- Para las páginas de pago, las cabeceras clave son CSP, HSTS, protección contra marcos, Referrer-Policy, Permissions-Policy, X-Content-Type-Options y Cache-Control: no-store.
- Debilitar o eliminar una cabecera es un paso habitual en un ataque, y no cambia el aspecto de la página.
- PCI DSS 11.6.1 pide alertas cuando las cabeceras HTTP cambian sin autorización.
- Construya la CSP para sus propias páginas y pruébela primero en modo solo informe.
Preguntas frecuentes
- ¿Qué cabeceras de seguridad HTTP son las más importantes en una página de pago?
- Content-Security-Policy es la más potente, seguida de Strict-Transport-Security, la protección contra marcos (frame-ancestors de CSP, con X-Frame-Options para navegadores antiguos), Referrer-Policy, Permissions-Policy, X-Content-Type-Options y Cache-Control: no-store.
- ¿PCI DSS enumera las cabeceras que debo configurar?
- El requisito 11.6.1 habla de avisar de cambios no autorizados en las cabeceras HTTP de las páginas de pago tal como las recibe el navegador; es un requisito de detección y no da una lista fija de cabeceras que configurar. Qué cabeceras importan para sus páginas es una decisión que debe explicar a su evaluador.
- ¿Sigue haciendo falta X-Frame-Options si uso frame-ancestors?
- Los navegadores modernos respetan la directiva frame-ancestors de CSP, que es más flexible. Muchos sitios siguen enviando X-Frame-Options para navegadores antiguos. Si están presentes ambas, los navegadores que admiten frame-ancestors usan esa.
- ¿Puedo configurar una Política de Seguridad de Contenido en una etiqueta meta?
- En parte. Una etiqueta meta puede llevar la mayoría de las directivas de CSP, pero no frame-ancestors, report-uri ni sandbox, y se aplica solo cuando el navegador la ha procesado. Una cabecera HTTP real es la mejor opción.
Leer la guía completa: Cabeceras de seguridad HTTP para páginas de pago
Política de Seguridad de Contenido (CSP) en pagos
CSP para páginas de pago: script-src, nonces, hashes, strict-dynamic, por qué unsafe-inline y los comodines la anulan, report-to y modo solo informe.
Una Política de Seguridad de Contenido es una cabecera HTTP que indica al navegador qué orígenes de scripts, marcos, imágenes y conexiones puede usar una página, y adónde puede enviar datos. En una página de pago, una política estricta basada en nonces o hashes puede impedir que se ejecuten skimmers inyectados y limitar adónde pueden ir los datos robados. Las listas de hosts permitidos, 'unsafe-inline' y los comodines la debilitan mucho, y necesita pruebas en modo solo informe antes de aplicarse.
Puntos clave
- Una CSP puede impedir que se ejecute un script inyectado y limitar adónde envía datos una página, lo que la hace uno de los controles más fuertes del lado del navegador.
- script-src con nonces o hashes (y opcionalmente strict-dynamic) es mucho más fuerte que una lista de hosts permitidos.
- 'unsafe-inline', 'unsafe-eval', los comodines y los orígenes data: debilitan o anulan una política.
- Despliegue en modo solo informe, revise los informes y luego aplique.
- Una CSP respalda el 6.4.3 pero no sustituye los controles de integridad, y como cabecera debe monitorearse a su vez conforme al 11.6.1.
Preguntas frecuentes
- ¿Qué hace unsafe-inline en una CSP?
- Permite que se ejecute cualquier script en línea y cualquier manejador de eventos en línea, incluido uno que inyecte un atacante, lo que elimina la mayor parte de la protección contra XSS y skimmers. Cuando la política también tiene un nonce o un hash, los navegadores modernos ignoran unsafe-inline.
- ¿Debo usar nonces o hashes?
- Use nonces cuando las páginas se generan en cada solicitud, porque un nonce nuevo por respuesta es lo más flexible. Use hashes para scripts en línea estáticos que cambian poco. Ambos son más fuertes que una lista de hosts permitidos.
- ¿Una Política de Seguridad de Contenido detiene los skimmers?
- Puede bloquear un skimmer que se cargue desde un origen no aprobado y puede impedir que envíe datos a una dirección no aprobada. No puede detener uno que llegue dentro de un script permitido o desde un host permitido, por eso se combina con controles de integridad, un inventario y monitoreo.
- ¿Es seguro usar el modo solo informe en una página de pago en producción?
- Sí. En modo solo informe el navegador no aplica nada; solo informa. Es la forma habitual de saber qué bloquearía una política antes de activar su aplicación.
Leer la guía completa: Política de Seguridad de Contenido (CSP) en pagos
Integridad de Subrecursos (SRI) explicada
La Integridad de Subrecursos (SRI) permite al navegador verificar un script con un hash. Cómo funciona integrity, qué no protege y por qué se rompe.
La Integridad de Subrecursos (SRI) permite que una página web indique, en la propia etiqueta del script, cuál debe ser el contenido exacto de un archivo externo. El navegador descarga el archivo, calcula su hash y se niega a ejecutarlo si el hash no coincide. La SRI protege contra que un archivo se cambie en el servidor que lo aloja, pero no puede proteger los scripts que cambian a propósito, los que se construyen sobre la marcha, los scripts en línea ni la página que lleva la etiqueta.
Puntos clave
- La SRI pone en la etiqueta del script un hash del archivo esperado; el navegador bloquea el archivo si su contenido difiere.
- Para archivos de otro origen necesita crossorigin="anonymous" y una cabecera CORS del host del archivo.
- Protege contra un archivo cambiado en el host, no contra scripts dinámicos, scripts en línea, scripts que cargan otros o una página comprometida.
- Las actualizaciones del proveedor romperán un script fijado a menos que gestione los hashes y las versiones de forma deliberada.
- Use la SRI junto con la CSP, un inventario y la detección de cambios.
Preguntas frecuentes
- ¿Qué hace el atributo integrity?
- Indica al navegador el hash esperado de un archivo externo. El navegador calcula el hash de lo que descarga y ejecuta el archivo solo si el resultado coincide.
- ¿Por qué la SRI necesita el atributo crossorigin?
- El navegador solo puede inspeccionar el contenido de un archivo de otro origen para calcular su hash si el servidor lo permite mediante CORS. El atributo crossorigin convierte la solicitud en una solicitud CORS, y el servidor debe responder con una cabecera Access-Control-Allow-Origin adecuada.
- ¿Habría detenido la SRI el ataque a polyfill.io?
- Solo en los sitios que hubieran fijado un archivo por su hash, lo cual era difícil porque el servicio generaba código distinto según la solicitud del visitante. Las respuestas habituales fueron alojar una copia revisada o eliminar la dependencia.
- ¿La SRI cumple PCI DSS 6.4.3?
- Puede ser un método para asegurar la integridad de scripts externos estáticos, que es parte del 6.4.3. No cubre scripts en línea ni dinámicos, y el 6.4.3 también necesita autorización y un inventario, así que suele ser una capa entre varias. Su evaluador decide qué es suficiente.
Leer la guía completa: Integridad de Subrecursos (SRI) explicada
Riesgo de seguridad de los gestores de etiquetas
Por qué los gestores de etiquetas amplían la superficie de ataque en pagos y cómo gobernarlos: accesos, aprobaciones, inventario, CSP y monitoreo.
Un gestor de etiquetas permite añadir, cambiar y quitar scripts de un sitio web desde una consola web, sin una publicación de código. Esa comodidad es también el riesgo: cualquiera que pueda publicar puede poner JavaScript en todas las páginas, incluidas las de pago, y las etiquetas que añade suelen cargar más scripts. Bien gobernado, con accesos estrictos, aprobaciones, un inventario y monitoreo, un gestor de etiquetas puede usarse con seguridad; sin gobierno en una página de pago, es una puerta abierta permanente para un skimmer.
Puntos clave
- Un gestor de etiquetas convierte el permiso de publicar en ejecución de código en todas las páginas, incluidas las de pago.
- Las etiquetas suelen cargar más scripts, así que la lista de la consola no muestra todo lo que se ejecuta.
- El control más fuerte es mantener las etiquetas de marketing fuera de las páginas de pago, o usar un contenedor aparte y restringido.
- Limite y proteja el acceso para publicar, exija aprobaciones y conserve el historial de versiones y los registros de auditoría.
- Compare lo que carga realmente la página de pago con la lista aprobada después de cada publicación.
Preguntas frecuentes
- ¿Debo cargar un gestor de etiquetas en mi página de pago?
- Cada gestor de etiquetas en una página de pago amplía la superficie de ataque. Muchas organizaciones lo dejan fuera del paso de pago o usan un contenedor aparte con una lista corta y revisada. Si lo carga, aplique accesos estrictos, aprobaciones y monitoreo.
- ¿Los requisitos de PCI DSS cubren los scripts cargados por un gestor de etiquetas?
- En la práctica sí: el requisito 6.4.3 abarca todos los scripts que se cargan y se ejecutan en el navegador del consumidor en una página de pago, sea cual sea lo que los cargue. Su evaluador decide cómo se aplica a su entorno.
- ¿Cómo puedo auditar lo que hace un gestor de etiquetas?
- Revise el historial de versiones y el registro de auditoría del contenedor, compare la lista de etiquetas con su inventario aprobado y, sobre todo, observe lo que la página de pago carga realmente en un navegador después de cada publicación.
- ¿El etiquetado del lado del servidor elimina el riesgo?
- Reduce el código de terceros en el navegador del visitante, pero no elimina la necesidad de control de acceso, aprobaciones y monitoreo, y traslada la confianza a su configuración del lado del servidor.
Leer la guía completa: Riesgo de seguridad de los gestores de etiquetas
Cómo crear un inventario de scripts de la página de pago
Cómo descubrir, documentar y justificar cada script de una página de pago, qué registrar y qué espera un evaluador como evidencia de PCI DSS 6.4.3.
Un inventario de scripts de la página de pago es una lista actual de cada script que se ejecuta en cada página de pago, con quién lo aprobó, por qué es necesario, cómo se asegura su integridad y cómo se carga. Debe construirse a partir de lo que realmente carga el navegador, no de su código fuente, porque los gestores de etiquetas y los scripts que cargan otros scripts añaden código que usted nunca escribió. Es el núcleo de PCI DSS 6.4.3 y la evidencia que un evaluador le pedirá ver.
Puntos clave
- El inventario enumera cada script de cada página de pago, con origen, forma de carga, justificación, responsable, aprobación y método de integridad.
- Constrúyalo a partir de lo que carga un navegador real, en todo el flujo de pago y sus variaciones, no solo del código fuente.
- Cada entrada necesita un motivo escrito que un revisor pueda comprobar; sin motivo, normalmente el script no tiene lugar en la página.
- Vuelva a aprobar los scripts cuando cambien y revise la lista periódicamente.
- Los evaluadores buscan un proceso vivo con historial, no una instantánea única.
Preguntas frecuentes
- ¿Qué cuenta como página de pago para el inventario?
- Las páginas donde se introducen datos de tarjeta o donde se incrusta un formulario de pago y, según cómo acepte pagos, las páginas que pueden afectarlas. La orientación del PCI SSC lo trata en detalle; acuerde la lista de páginas con su adquirente o evaluador.
- ¿Qué nivel de detalle necesita la justificación escrita?
- El suficiente para que un revisor pueda juzgar si el script sigue siendo necesario: qué hace, por qué lo necesita la página de pago y quién depende de él. Una sola palabra como «analítica» es muy poco.
- ¿Con qué frecuencia debe actualizarse el inventario?
- Cada vez que un script cambie, y comprobarse automáticamente con una periodicidad acorde a su frecuencia de detección (al menos cada siete días para el 11.6.1, salvo que un análisis de riesgos respalde otro intervalo), con una revisión humana completa a intervalos planificados.
- ¿Los scripts en línea van en el inventario?
- Sí. Se ejecutan en el navegador como cualquier otro script. Registre lo que hacen y conserve un hash o una copia para que pueda verse un cambio.
Leer la guía completa: Cómo crear un inventario de scripts de la página de pago
Cómo detectar la manipulación en páginas de pago
Líneas base, detección de cambios, frecuencia, alertas, respuesta a incidentes y conservación de evidencia ante la manipulación de la página de pago.
Detectar la manipulación del lado del cliente significa saber qué debe entregar una página de pago (una línea base de scripts, contenido y cabeceras), comprobar periódicamente lo que reciben realmente los navegadores y avisar a las personas cuando difieren, con un proceso claro para decidir si el cambio estaba autorizado. Este artículo describe ese proceso de forma neutral respecto de los proveedores, con la frecuencia, las alertas, la respuesta a incidentes y la evidencia que conviene conservar.
Puntos clave
- Una línea base de scripts, contenido y cabeceras, construida con elementos revisados y aprobados, es lo que hace visible el cambio.
- Avise de scripts nuevos, eliminados o modificados, formularios alterados, cabeceras debilitadas y nuevos dominios de terceros, y vincule las alertas a las aprobaciones para reducir el ruido.
- Observe lo que recibe el navegador del cliente; combine métodos y esté preparado para explicar la combinación.
- Lo semanal es un mínimo conforme al 11.6.1; muchas organizaciones comprueban a diario y después de cada publicación.
- Planifique la respuesta de antemano y conserve evidencia de ejecuciones, alertas y decisiones.
Preguntas frecuentes
- ¿Con qué frecuencia debo comprobar si hay manipulación en las páginas de pago?
- PCI DSS 11.6.1 exige al menos una vez cada siete días, o la frecuencia de un análisis de riesgos específico documentado. Muchas organizaciones comprueban a diario y también después de cada publicación, publicación en el gestor de etiquetas o cambio de proveedor.
- ¿Puedo confiar solo en el monitoreo del lado del servidor?
- No. No puede ver los cambios hechos por scripts de terceros, un gestor de etiquetas o una CDN en la entrega o en el navegador. Revisar lo que recibe el navegador cubre esa brecha.
- ¿La detección previene los ataques?
- No. La detección acorta el tiempo que un ataque pasa inadvertido. Los controles de prevención como una Política de Seguridad de Contenido, los controles de integridad, los parches y el control de acceso reducen la probabilidad de un ataque exitoso; ambos trabajan juntos.
- ¿Qué debe incluir una buena alerta?
- La página, el cambio (antes y después), la hora en que se vio por primera vez, si coincide con un cambio aprobado, quién es responsable de responder y un enlace a la evidencia.
Leer la guía completa: Cómo detectar la manipulación en páginas de pago
Cómo elegir una herramienta PCI DSS 6.4.3 y 11.6.1
Preguntas para elegir una herramienta de monitoreo 6.4.3 y 11.6.1 y lo que dicen diez herramientas en sus páginas, también sobre el inicio de sesión.
Las herramientas para PCI DSS 6.4.3 y 11.6.1 se diferencian en cómo ven su página de pago (un navegador real fuera de su sitio, un script dentro de la página, un proxy o una Política de Seguridad de Contenido), en si bloquean o solo detectan, en qué evidencia conservan y, sobre todo, en si pueden llegar a las páginas de pago que están detrás de un inicio de sesión. Haga las mismas nueve preguntas a todos los proveedores, compruebe las respuestas por escrito y pida a su evaluador que confirme qué aceptará. Más abajo, una tabla recoge lo que dicen diez herramientas en sus propias páginas.
Puntos clave
- Haga las mismas nueve preguntas a todos los proveedores y consiga las respuestas por escrito.
- La pregunta que separa las herramientas es si llegan a las páginas de pago tras un inicio de sesión o a mitad de la compra.
- Ninguna de las otras nueve páginas leídas para esta guía describe inicios de sesión: la de cside menciona "the user flow leading to the payment page" y la de TamperDetect incluye "Dynamic & Gated Content" sin explicarlo. Pregunte directamente a cada proveedor.
- Detectar y bloquear son capacidades distintas; los requisitos piden inventario, autorización, integridad y alertas.
- Su evaluador decide qué es suficiente; confírmelo pronto.
Preguntas frecuentes
- ¿Qué herramienta es la mejor para PCI DSS 6.4.3 y 11.6.1?
- Depende de cómo estén construidas y entregadas sus páginas de pago. Las páginas tras un inicio de sesión, los formularios de pago de terceros, la evidencia que debe producir y si desea bloquear o solo detectar cambian la respuesta. Use las nueve preguntas anteriores y consulte a su evaluador qué acepta.
- ¿Necesito una herramienta que bloquee scripts?
- Los requisitos piden un inventario de scripts, una forma de autorizarlos, garantía de integridad y alertas ante cambios. Algunas herramientas también bloquean; otras solo detectan e informan. PCI Monitor solo detecta e informa, por lo que funciona junto con controles como una Política de Seguridad de Contenido.
- ¿Debe una herramienta de monitoreo cubrir las páginas tras un inicio de sesión?
- Si una página de pago forma parte de su flujo de pago, está dentro del alcance sea cual sea la forma de llegar a ella. Pregunte al proveedor cómo se alcanza la página tras el inicio de sesión y cómo gestiona la herramienta un segundo paso de inicio de sesión.
- ¿Cómo se elaboró la tabla de proveedores?
- Leyendo la página de cada empresa el 23 de octubre de 2026 y anotando solo lo que afirma. No se usaron opiniones, clasificaciones ni otras comparaciones. Quien publica esta guía fabrica una de las herramientas de la lista, por lo que la declaración y la vía de corrección figuran bajo la tabla.
Leer la guía completa: Cómo elegir una herramienta PCI DSS 6.4.3 y 11.6.1
Referencia
Un vocabulario común para su equipo, sus proveedores y su evaluador.
Glosario de seguridad del lado del cliente y PCI DSS
Definiciones claras de skimming, Magecart, CSP, SRI, nonce, gestor de etiquetas, línea base, detección de manipulación, SAQ, QSA, ASV y otros términos.
Este glosario da definiciones breves y claras de los términos usados en toda la Biblioteca de seguridad: los ataques (skimming, Magecart, formjacking), los controles del navegador (CSP, SRI, nonce, cabeceras de seguridad), las prácticas (línea base, detección de manipulación, inventario) y el vocabulario de PCI DSS (página de pago, SAQ, QSA, ASV, TPSP). Las definiciones están simplificadas a modo de orientación; la autoridad son los propios estándares.
Puntos clave
- Skimming, Magecart, e-skimming y formjacking describen el robo de tarjetas mediante un script malicioso en el navegador.
- La CSP, la SRI, los nonces y las cabeceras de seguridad son controles del navegador; las líneas base, los inventarios y la detección de manipulación son prácticas que los rodean.
- Los requisitos 6.4.3 (gestionar scripts) y 11.6.1 (detectar cambios) son los requisitos de PCI DSS dirigidos a los scripts de la página de pago.
- SAQ, ROC, QSA, ASV y TPSP son los roles y documentos de la validación de PCI DSS; su adquirente decide cuáles se le aplican.
Preguntas frecuentes
- ¿Cuál es la diferencia entre un nonce y un hash de CSP?
- Un nonce es un valor aleatorio que cambia con cada respuesta y se adjunta a las etiquetas de script aprobadas. Un hash es una huella del contenido de un script concreto. Ambos permiten que el navegador reconozca scripts aprobados; los nonces convienen a páginas dinámicas y los hashes a scripts estáticos.
- ¿Cuál es la diferencia entre un QSA y un ASV?
- Un QSA evalúa el cumplimiento de una organización con los requisitos de PCI DSS. Un ASV realiza los análisis externos de vulnerabilidades que exige PCI DSS. Ambos están calificados o aprobados por el PCI SSC para sus funciones.
- ¿Qué significa «página de pago» en PCI DSS 6.4.3 y 11.6.1?
- En términos generales, una página donde se introducen datos de tarjeta o una que incluye un formulario de pago incrustado. La orientación del PCI SSC trata los límites, y su adquirente o evaluador decide cuáles de sus páginas cuentan.
Leer la guía completa: Glosario de seguridad del lado del cliente y PCI DSS