Los requisitos PCI DSS 4.0.1 6.4.3 y 11.6.1 gobiernan los scripts y cabeceras HTTP de tus páginas de pago. 6.4.3 te obliga a inventariar, autorizar y asegurar la integridad de cada script. 11.6.1 te obliga a detectar y alertar sobre cambios no autorizados en los scripts y cabeceras de seguridad de esa página. Ambos son obligatorios desde 2025-03-31. Esta guía desglosa cada cláusula, qué significa para la página en producción y qué evidencia específica espera ver un QSA.
Estos dos requisitos existen por el e-skimming. Los atacantes estilo Magecart no necesitan vulnerar tu servidor. Alteran un script que carga el navegador y capturan datos de titulares de tarjeta directamente del formulario mientras el usuario escribe. Un iframe de procesador no cubre la página que lo enmarca. cside vive en ese hueco exacto: registra cada script que ejecutan navegadores reales en la página de pago, captura autorización y marca cambios de integridad y cabeceras cuando ocurren.
Qué exige realmente el requisito 6.4.3
6.4.3 establece tres obligaciones para cada script de página de pago. Léelas como cláusulas separadas, porque un QSA lo hará:
- Un método confirma que cada script está autorizado antes de cargar o ejecutarse.
- Un método asegura la integridad de cada script.
- Se mantiene un inventario de scripts con una justificación escrita de por qué cada uno es necesario.
"Autorizado" y "necesario" son las dos palabras que hacen tropezar a los equipos. La autorización es una decisión registrada: un aprobador nombrado firmó que este script puede correr en una página dentro del alcance de datos de tarjeta. La justificación es la razón de negocio por la que existe. Un píxel de tracking que marketing añadió el trimestre pasado suele no tener ninguna de las dos, justo el tipo de hallazgo que aflora 6.4.3.
El alcance va más allá del código propio. El control cubre cada script que el navegador ejecuta en la página: tus bundles, SDKs de terceros y los scripts de cuarta parte que esos vendors traen en runtime. Un tag manager que inyecta tres scripts más después de cargar la página son tres entradas más en tu inventario, y esas entradas cambian sin un deploy de tu lado.
El PCI SSC lista hashes Subresource Integrity (SRI) y Content-Security-Policy como mecanismos de integridad de ejemplo. Sirven para assets estáticos. Se rompen en cuanto un script es dinámico. Una etiqueta de analítica o herramienta A/B que se actualiza legítimamente invalida el hash, así que SRI fijado bloquea una actualización buena o se elimina y deja de proteger nada. Content Security Policy tiene el mismo límite: no puede responder por lo que hace en runtime un script permitido. Por eso la integridad en páginas de pago reales debe evaluarse sobre lo ejecutado, no sobre un hash fijado en build.
Qué exige realmente el requisito 11.6.1
11.6.1 es un control de detección, no de gestión. Exige un mecanismo de detección de cambios y manipulación que hace dos cosas:
- Alerta al personal sobre modificación no autorizada (incluidos indicadores de compromiso, cambios, altas y bajas) de las cabeceras HTTP y el contenido de páginas de pago tal como las recibe el navegador del consumidor.
- Evalúa las cabeceras y contenido recibidos con una frecuencia definida por tu targeted risk analysis bajo el requisito 12.3.1, o al menos una vez cada siete días.
La frase "tal como las recibe el navegador del consumidor" sostiene el requisito. 11.6.1 no pregunta qué sirvió tu CDN ni qué contiene tu repo. Pregunta qué renderizó el navegador, después de cada redirección, inyección y modificación runtime. Un skimmer lee navigator.webdriver, propiedades de automatización ausentes y falta de interacción real para reconocer un escáner, y luego sirve código limpio al escáner y el payload a un humano. Un control que solo ve la versión escaneada nunca alerta.
Las cabeceras HTTP están en alcance porque son superficie de ataque, no detalle de configuración. Una cabecera Content-Security-Policy debilitada o eliminada permite cargar un script malicioso que la política debía bloquear. 11.6.1 quiere que notes que la cabecera cambió, y que lo notes en la respuesta entregada, no en la configuración de origen.
Cómo se reparten el trabajo los dos requisitos
6.4.3 gobierna lo que permites; 11.6.1 gobierna lo que ocurrió en la página.
| Pregunta | Requisito | Qué gobierna | Modo de fallo que captura |
|---|---|---|---|
| ¿Qué scripts están permitidos aquí y por qué? | 6.4.3 | Autorización, justificación, integridad, inventario | Un script en alcance sin aprobación o documentación |
| ¿La página o sus cabeceras cambiaron sin aprobación? | 11.6.1 | Detección y alerta sobre cambios de scripts y cabeceras | Una manipulación viva que el inventario nunca notó |
| ¿Con qué frecuencia revisamos la página entregada? | 11.6.1 + 12.3.1 | Frecuencia, con mínimo de siete días | Revisiones obsoletas que pierden cambios transitorios |
Trátalos como un bucle, no como dos proyectos. Un inventario sin detección viva es una lista que se vuelve obsoleta cuando un vendor publica una actualización. Detección sin inventario produce alertas que nadie puede triar, porque no hay línea base de qué significa "autorizado".
La evidencia que debe producir cada control
Un QSA evalúa el cumplimiento a partir de artefactos. Mapea cada cláusula al registro que genera para entregar exactamente lo que pide.
| Cláusula | Artefacto de evidencia | Qué debe mostrar |
|---|---|---|
| Inventario 6.4.3 | Inventario de scripts vinculado a páginas en alcance | URL, owner y última versión vista de cada script |
| Autorización 6.4.3 | Registro de aprobación por script | Quién lo aprobó, cuándo y qué datos toca |
| Justificación 6.4.3 | Nota de razón de negocio por script | Por qué el script es necesario en una página de pago |
| Integridad 6.4.3 | Historial de integridad | Cómo se confirma que cada script no se alteró en el tiempo |
| Detección 11.6.1 | Log de cambios con alertas | Timestamp, diff, página y quién fue notificado |
| Evaluación de cabeceras 11.6.1 | Historial de cabeceras por página | Valores de cabeceras de seguridad y cambios entre cargas |
| Frecuencia 11.6.1 | Análisis de riesgo + cadencia de revisión | Justificación 12.3.1 y prueba de que las revisiones corrieron |
El artefacto que más falta a los equipos es el historial de integridad y el historial de cabeceras en el tiempo. Una captura única prueba que la página estuvo limpia una vez. Un QSA evaluando 11.6.1 quiere evidencia de que habrías detectado un cambio: un registro fechado a lo largo de muchas cargas reales, no una captura de pantalla.
Por qué un procesador no cierra esto por ti
Una suposición común es que alojar campos de pago en un iframe de Stripe, Adyen o Braintree empuja 6.4.3 y 11.6.1 al procesador. No lo hace. El iframe está aislado, pero la página del comercio que lo enmarca no. Tu analítica, herramienta A/B, session replay y widgets de chat corren en el mismo contexto de navegador de nivel superior, y un script ahí puede leer el DOM, superponer un campo falso sobre el iframe o redirigir el formulario al enviarse. La actualización de SAQ A de enero de 2025 estrechó la elegibilidad porque pocas páginas de pago reales están libres de scripts de terceros, y añadió un criterio de confirmar que tu sitio no es susceptible a ataques basados en scripts, algo difícil de probar sin monitorización. Los requisitos se quedan con la página que sirves.
Por qué la amenaza es cada vez más difícil de escanear
La razón por la que 11.6.1 insiste en la página entregada es que el tooling atacante está construido para derrotar cualquier cosa que no sea real. Navegadores headless e instrumentados filtran señales: una bandera navigator.webdriver, objetos runtime chrome ausentes, artefactos Runtime de Chrome DevTools Protocol y timing imposible marcan una sesión como no humana. Los skimmers fingerprintan esas señales y se quedan dormidos ante crawlers y comprobaciones sintéticas.
El tooling de evasión también avanzó en la otra dirección. El informe de cside sobre el futuro de la seguridad web encontró que playwright-stealth, automatización afinada para suprimir esas fugas, creció aproximadamente 10x en uso durante 2025. La conclusión práctica para 6.4.3 y 11.6.1: la integridad y la detección de cambios deben correr donde se introducen realmente los datos de tarjeta, en la sesión real del navegador, no desde un punto externo que un script evasivo puede identificar y evitar.
Cómo cside produce esta evidencia en la capa del navegador
cside instrumenta la página de pago en navegadores reales, que es la superficie a la que apuntan ambos requisitos.
- Para 6.4.3, captura el inventario completo de scripts, incluidos los scripts de cuarta parte que los vendors cargan en runtime, registra autorización y justificación junto a cada entrada, y conserva historial de integridad para probar que un script se mantuvo intacto entre versiones.
- Para 11.6.1, monitoriza contenido de scripts y cabeceras HTTP de seguridad en la página entregada, los compara entre cargas y alerta ante cambios no autorizados, con un registro fechado que responde la pregunta de frecuencia de 12.3.1 sin extracción manual semanal.
- También aflora el payload runtime de cada script y vincula comportamiento de scripts con señales de dispositivo, IP real y VPN/proxy, para que un cambio marcado llegue con contexto en vez de solo un hash distinto.
Como observa lo que se ejecutó y no lo que se mostró a un escáner, cside captura la misma evidencia de navegador que un atacante de e-skimming intenta ocultar. Eso alinea el workflow de cumplimiento con la amenaza real. Para el despliegue operativo y la vista de reporting QSA, las guías de abajo profundizan.
Lecturas adicionales en cside
- Cómo cumplir PCI 6.4.3 y 11.6.1
- Qué buscan los QSAs al evaluar 6.4.3 y 11.6.1
- Comparación de soluciones para PCI DSS 6.4.3 y 11.6.1
- Qué es client-side security
- cside PCI Shield
- La forma más rápida de cumplir PCI DSS 6.4.3 y 11.6.1
- PCI SSF o PCI DSS: qué estándar aplica en tu caso
A fecha de 2026-06-18, trata esto como una guía operativa, no como asesoramiento legal. Confirma el texto exacto del control con tu QSA, asesor jurídico o responsable de riesgos.
