PCI DSS 4.0 en Magento: protege tu checkout de Magecart con CSP y SRI

• Qué cambió: los requisitos 6.4.3 y 11.6.1 son obligatorios desde el 31 de marzo de 2025.
• Magento 2.4.7 o superior: CSP en modo restrictivo en las páginas de pago y SRI para los JavaScript locales de esas páginas.
• Hyvä Checkout 1.3 o superior: CSP estricta, sin unsafe-inline ni unsafe-eval, y no se puede desactivar.
• Lo que falta casi siempre: el inventario de scripts con justificación y un monitoreo que avise de cambios. CSP y SRI no lo cubren solos.
• Si cobras con iframe o redirección: confirma con tu pasarela qué te toca para el cuestionario SAQ A.

En este artículo:

• Qué piden 6.4.3 y 11.6.1
• Qué cambia si usas iframe o redirección
• Qué trae Magento 2.4.7
• Cómo funciona Hyvä Checkout con CSP estricta
• Qué no cubren CSP y SRI
• Cómo armar el inventario de scripts
• Qué hacer según tu tienda
• Checklist antes del Buen Fin
• Preguntas frecuentes

Magecart es el nombre que se usa para el robo de tarjetas con JavaScript malicioso metido en el checkout. El cliente paga como siempre, pero un script copia los datos de su tarjeta y los manda a otro servidor. El atacante no necesita entrar a tu pasarela: le basta con alterar lo que carga el navegador.

En Magento el riesgo no es teórico. Sansec reportó en octubre de 2024 que 4,275 tiendas Adobe Commerce y Magento, alrededor del 5% del total, terminaron ese verano con un skimmer en su checkout tras la vulnerabilidad CosmicSting (CVE-2024-34102). Los atacantes insertaban el código a través de bloques CMS.

Por eso PCI DSS 4.0 en Magento ya no es solo un tema de tu pasarela. Si buscas la lista general de temporada alta, lee el checklist técnico del Buen Fin 2026. Si te preocupan los bots que prueban tarjetas, está la guía de carding en Magento. Aquí nos centramos en los scripts de la página de pago.

¿Qué piden los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0?

Piden dos cosas: controlar los scripts de la página de pago y enterarte si alguien la modifica. PCI DSS 4.0 los añadió para reducir el e-skimming, siguen en la versión 4.0.1 y son obligatorios desde el 31 de marzo de 2025, según el PCI Security Standards Council (PCI SSC).

Requisito 6.4.3: scripts de la página de pago. Para cada script que se carga y ejecuta en el navegador del cliente debe haber:

• Un método para confirmar que está autorizado.
• Un método para asegurar su integridad.
• Un inventario de todos los scripts con una justificación escrita, técnica o de negocio.

Requisito 11.6.1: detección de cambios. Debe existir un mecanismo que:

• Alerte al personal ante cambios no autorizados en los encabezados HTTP de seguridad y en el contenido de los scripts de la página de pago, tal como los recibe el navegador.
• Revise esos encabezados y la página de pago.
• Corra al menos cada semana, o con la frecuencia que defina un análisis de riesgo (requisito 12.3.1).

La guía del PCI SSC de marzo de 2025 aclara que la norma no impone una tecnología. Menciona Content Security Policy (CSP) y Subresource Integrity (SRI) como ejemplos y acepta otras soluciones. También aclara que los scripts de 3-D Secure no requieren validación bajo 6.4.3.

¿Aplica el requisito 6.4.3 si uso una pasarela con iframe o redirección?

Depende de cómo cobres. En enero de 2025 el PCI SSC quitó los requisitos 6.4.3, 11.6.1 y 12.3.1 del cuestionario SAQ A. A cambio agregó un criterio de elegibilidad: confirmar que tu sitio no es susceptible a ataques de scripts que afecten tu ecommerce.

• Pasarela embebida (iframe o formulario del proveedor dentro de tu checkout): aplica ese criterio. Según la FAQ 1588 del PCI SSC, lo cumples aplicando técnicas como las de 6.4.3 y 11.6.1, o con una confirmación de tu pasarela de que su solución protege tu página de pago.
• Redirección a la página de la pasarela: la misma FAQ dice que ese criterio no aplica.
• Si no calificas para SAQ A: el PCI SSC recuerda que los requisitos siguen en la norma completa; quitarlos del cuestionario no los elimina.

Quien valida tu cumplimiento es tu banco adquirente o un asesor certificado (QSA). Esta guía te ayuda a preparar la parte técnica en Magento, no sustituye esa revisión.

¿Qué trae Magento 2.4.7 para cumplir PCI DSS 4.0?

Adobe ajustó el módulo Magento_Csp para PCI 4.0. Desde Magento Open Source y Adobe Commerce 2.4.7, la CSP está en modo restrictivo por defecto en las páginas de pago del storefront y del Admin, y en modo report-only en el resto del sitio.

• CSP restrictiva en pago: el encabezado de esas páginas ya no incluye unsafe-inline en script-src. Solo corren los scripts inline que estén en la lista blanca.
• Nonce por solicitud: Magento\Csp\Helper\CspNonceProvider genera un valor único en cada carga para autorizar scripts inline.
• SRI: hashes de integridad para los JavaScript locales, por defecto solo en las páginas de pago del Admin y del storefront. Está en 2.4.4-p9, 2.4.5-p8, 2.4.6-p6, 2.4.7, 2.4.8 y posteriores. Desde 2.4.9 también cubre archivos minificados, empaquetados y combinados.
• Reportes de violaciones: en Stores > Settings > Configuration > Security > Content Security Policy defines a qué URI se envían, con una propia para el checkout y otra para Create Order del Admin.

Dos matices de la documentación de Adobe. Antes de 2.4.7 todas las páginas estaban en report-only, que avisa pero no bloquea. Y en la configuración por defecto eval() sigue permitido. Si tu tienda está por debajo de 2.4.7, revisa primero los requisitos de Magento 2.4.8 para planear el upgrade.

Cómo autorizar un script inline o un dominio externo

Si al pasar a modo restrictivo ves en la consola el error Refused to execute inline script because it violates the following Content Security Policy directive, Adobe propone dos salidas: renderizar el script con SecureHtmlRenderer o autorizarlo con el nonce provider. Para dominios externos, como el de tu pasarela, se usa un csp_whitelist.xml en tu módulo:

<?xml version="1.0"?>
<csp_whitelist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Csp:etc/csp_whitelist.xsd">
    <policies>
        <policy id="script-src">
            <values>
                <value id="mi-pasarela" type="host">https://js.pasarela.example</value>
            </values>
        </policy>
    </policies>
</csp_whitelist>

Agrega cada dominio solo a la política que necesita, por ejemplo script-src y no default-src, como recomienda Adobe. Cada dominio nuevo en la lista también debe entrar a tu inventario de scripts.

¿Cómo maneja Hyvä Checkout la CSP estricta?

Hyvä Checkout 1.3.x y posteriores aplican CSP estricta en todas las páginas del checkout: sin unsafe-inline ni unsafe-eval y con autorización por nonce. Hyvä aclara que es un requisito obligatorio para PCI DSS 4.0 y que no se puede desactivar.

• Cada script inline lleva nonce: se registra con $hyvaCsp->registerInlineScript() justo después de cerrar el </script>.
• Sin inyección dinámica: los scripts que se agregan con JavaScript después de cargar la página no se ejecutan. Revisa qué cargaban tus etiquetas de marketing en el checkout.
• Alpine CSP: los componentes Alpine del checkout deben seguir el build CSP de Alpine, sin expresiones inline.
• Componentes compartidos: el header, el footer, el aviso de cookies o los mensajes también aparecen en el checkout. Desde la versión 1.3.15 del tema por defecto de Hyvä, sus scripts compartidos con el checkout ya son compatibles con CSP estricta.

No tienes que migrar todo el tema para empezar. Hyvä documenta tres caminos: CSP estricta solo en el checkout, checkout estricto con botones de pago por redirección, o el tema completo compatible con CSP. Si sigues con el checkout de Luma, compara opciones en Hyvä Checkout vs checkout Luma o revisa nuestro servicio de Hyvä Theme.

¿Y si quiero CSP estricta en todo el sitio con Hyvä?

Hyvä ofrece una versión del tema compatible con CSP que usa Alpine CSP. Su documentación avisa dos cosas antes de activarla:

• Los scripts dentro de contenido CMS dejan de funcionar cuando quitas unsafe-inline. Es un costo para marketing, pero también dificulta la vía que usaron los atacantes de CosmicSting, que metían skimmers en bloques CMS.
• La caché de página integrada en PHP no guarda el encabezado CSP. Para CSP estricta en páginas cacheadas necesitas Varnish u otro proxy, como Fastly. El checkout no se ve afectado porque no se cachea.

¿Qué no cubren CSP y SRI por sí solos?

La guía del PCI SSC es clara en sus límites. CSP y SRI ayudan con la autorización y la integridad, pero no te dan el control completo:

• CSP no crea por sí misma una lista de scripts no autorizados ni alerta sobre cambios en los encabezados de seguridad.
• CSP no detecta si alguien borró un encabezado, ni si un script permitido cambió lo que hace, salvo que intente contactar un dominio no permitido.
• SRI no es práctico para scripts que cambian seguido, como muchos de terceros.
• SRI falla en silencio: bloquea el archivo pero no avisa a nadie.

Por eso, además de la configuración, necesitas tres cosas: un inventario con justificación, alguien que autorice los cambios y un mecanismo que revise la página como la recibe el navegador y alerte. La guía del PCI SSC menciona monitoreo de páginas, soluciones basadas en proxy y herramientas especializadas de gestión de scripts.

En Panamerik usamos IA en auditorías de seguridad y corrección de errores, y una persona del equipo revisa cada hallazgo y cada corrección antes de que llegue a producción. Si quieres ver cómo aplicamos ese criterio, lee cómo proteger Magento con inteligencia artificial.

¿Cómo armar el inventario de scripts de tu checkout?

La norma no dice cómo llevarlo. La guía del PCI SSC acepta desde una hoja de cálculo en sitios sencillos hasta herramientas automáticas en sitios complejos. Un orden práctico en Magento:

1. Lista lo que carga la página de pago. Abre el checkout con las herramientas de desarrollador del navegador, filtra por JS en la pestaña de red y anota cada archivo y su dominio. Revisa también el encabezado Content-Security-Policy de la respuesta.
2. Documenta cada script. Anota de dónde viene, para qué sirve en esa página, quién lo aprobó y cómo se asegura su integridad.
3. Quita lo que no se justifique. Si un script no tiene razón para estar donde se escribe la tarjeta, sácalo de esa página.
4. Pasa los dominios aprobados a la CSP con csp_whitelist.xml y deja el checkout en modo restrictivo.
5. Configura la URI de reportes y define quién los lee.
6. Programa la revisión de cambios al menos semanal, o con la frecuencia de tu análisis de riesgo, y decide a quién le llega la alerta.

¿Qué hacer primero según tu tienda?

Checklist de PCI DSS 4.0 antes del Buen Fin 2026

• Confirma tu versión de Magento o Adobe Commerce y, si aplica, la de Hyvä Checkout y del tema.
• Verifica que el checkout responde con CSP en modo restrictivo y sin unsafe-inline en script-src.
• Revisa la consola del checkout: sin errores de CSP en un pedido de prueba con cada método de pago.
• Ten el inventario de scripts del checkout con justificación y responsable.
• Configura la URI de reportes de CSP y asigna quién los revisa durante el evento.
• Define la revisión semanal de la página de pago y sus encabezados.
• Pide a tu pasarela su confirmación sobre protección contra scripts si usas iframe.
• Rota la llave de cifrado y revisa integraciones de API desconocidas si tu tienda estuvo expuesta a CosmicSting, como recomienda Sansec.

Conclusión

PCI DSS 4.0 en Magento se resume en saber qué scripts corren en tu página de pago, permitir solo esos y enterarte rápido si algo cambia. Magento 2.4.7 o superior e Hyvä Checkout 1.3 te dan la base con CSP y SRI. El inventario, la autorización y la revisión semanal los tienes que poner tú, y conviene tenerlos listos antes del Buen Fin.

Sigue profundizando con:

• Carding en Magento: cómo frenar pruebas de tarjetas robadas
• Buen Fin 2026: checklist técnico para Magento
• Seguridad Magento: cómo proteger la tienda y responder a incidentes
• PHP2Shell: vulnerabilidades PHP en Magento 2026
• Soporte Magento Panamerik

Sobre el autor

Panamerik dirige Panamerik, agencia especializada en Magento, Adobe Commerce y Hyvä desde Guadalajara. Su equipo diseña, desarrolla, integra y da soporte a tiendas en línea, con Cloudflare Enterprise vía Cloudways e IA en auditorías de seguridad siempre con revisión humana antes de producción.

Fuentes

• PCI SSC: Important Updates Announced for Merchants Validating to SAQ A (consultado el 7 de noviembre de 2026)
• PCI SSC: Coffee with the Council, guía de requisitos de ecommerce desde el 31 de marzo de 2025 (consultado el 7 de noviembre de 2026)
• PCI SSC: Payment Page Security and Preventing E-Skimming (information supplement, marzo de 2025) (consultado el 7 de noviembre de 2026)
• Adobe Experience League: Content security policy overview (consultado el 7 de noviembre de 2026)
• Adobe Experience League: Adobe Commerce 2.4.7 release notes (consultado el 7 de noviembre de 2026)
• Adobe Developer: Content Security Policies (consultado el 7 de noviembre de 2026)
• Adobe Developer: Subresource Integrity (consultado el 7 de noviembre de 2026)
• Hyvä Docs: Hyvä Theme CSP (consultado el 7 de noviembre de 2026)
• Hyvä Docs: Configuring CSP in Magento (consultado el 7 de noviembre de 2026)
• Hyvä Docs: Content Security Policy (CSP) for Hyvä Checkout (consultado el 7 de noviembre de 2026)
• Hyvä Docs: Strict CSP Mode in Hyvä Checkout (consultado el 7 de noviembre de 2026)
• Hyvä Docs: CSP Checkout without Migrating Your Full Theme (consultado el 7 de noviembre de 2026)
• Sansec: Thousands of Adobe Commerce stores hacked in competing CosmicSting campaigns (consultado el 7 de noviembre de 2026)