¿Usar Stripe te hace cumplir con PCI?
No. Usar Stripe reduce tu alcance de PCI DSS y puede llevarte a la autoevaluación SAQ A, que es más corta, pero no hace que cumplas por completo. Stripe certifica sus propios sistemas, no tu sitio web. Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 rigen los scripts de tu página de pago, y esa página sigue cargándose en el navegador de tu cliente. Siguen siendo tu responsabilidad.
Los equipos de comercio electrónico y de cumplimiento suelen pasar por alto esta brecha. Delegar la captura de la tarjeta a un procesador es valioso: saca los datos del titular de la tarjeta de tus servidores y reduce la cantidad de controles que autodeclaras. Pero "usamos Stripe" responde a una pregunta sobre dónde se procesan los números de tarjeta. No responde la pregunta que PCI DSS 4.0.1 ahora plantea: ¿qué está haciendo cada script en el navegador mientras tu cliente escribe su tarjeta?
Qué cubre realmente Stripe (y qué no)
Stripe es un proveedor de servicios de Nivel 1 de PCI DSS, y puedes usar Stripe para reducir el alcance de PCI DSS. Cuando usas Stripe Elements, campos alojados o Stripe Checkout, el número de tarjeta se ingresa en un iframe servido y controlado por Stripe. Los datos sensibles aterrizan en el entorno de Stripe, no en el tuyo. Esa es la reducción de alcance por la que estás pagando, y es real.
Lo que Stripe no hace es asumir la responsabilidad de la página que rodea su iframe. Tu página de checkout sigue siendo servida desde tu dominio, ensamblada por tu stack y decorada con tus scripts: analítica, gestores de etiquetas, repetición de sesiones, chat, SDK antifraude y cualquier cosa que un equipo de marketing haya agregado el trimestre pasado. Esos scripts se ejecutan en el mismo navegador que el flujo de pago.
| Aspecto | Stripe lo cubre | Sigue siendo tuyo (6.4.3 / 11.6.1) |
|---|---|---|
| Entrada y almacenamiento del número de tarjeta | Sí, dentro del iframe alojado de Stripe | No |
| La propia atestación de PCI DSS de Stripe | Sí, como proveedor de servicios de Nivel 1 | No |
| Scripts de terceros en la página de pago | No | Sí, inventaría y justifica cada uno (6.4.3) |
| Integridad de esos scripts (sin manipulación) | No | Sí, confirma la integridad (6.4.3) |
| Detección de manipulación y de cambios más alertas | No | Sí, implementa un mecanismo (11.6.1) |
| Encabezados HTTP que afectan la seguridad | No | Sí, monitorea cambios no autorizados (11.6.1) |
| Tu SAQ y AoC como comercio | No | Sí, te autoevalúas y atestas |
La división es clara. Stripe es responsable de los datos de la tarjeta, tú eres responsable del entorno del navegador a su alrededor. PCI DSS 4.0.1 hizo explícita esa segunda columna.
¿Qué exigen realmente los requisitos 6.4.3 y 11.6.1?
Ambos requisitos se introdujeron para abordar los ataques del lado del cliente, en los que se inyecta código malicioso en scripts que se ejecutan en el navegador del cliente. Pasaron a ser obligatorios el 31 de marzo de 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
Requisito 6.4.3: gestiona los scripts de tu página de pago. Para cada script que se carga y se ejecuta en la página de pago en el navegador del consumidor, debes:
- Mantener un inventario de todos los scripts, con justificación por escrito de por qué cada uno es necesario.
- Autorizar cada script antes de que se agregue o se modifique.
- Confirmar la integridad de cada script verificando que no ha sido modificado sin autorización.
Requisito 11.6.1: detecta la manipulación y alerta. Debes implementar un mecanismo de detección de cambios y de manipulación que:
- Alerte al personal sobre la modificación no autorizada de los encabezados HTTP y los scripts de la página de pago, tal como los recibe el navegador del consumidor.
- Evalúe la página recibida al menos una vez cada siete días, o con la frecuencia que defina tu análisis de riesgo dirigido.
6.4.3 dice conoce y autoriza tus scripts, y 11.6.1 dice obsérvalos en tiempo real y alerta cuando cambien. Ninguno de los dos lo satisface tu procesador de pagos, porque ninguno trata de adónde van los datos de la tarjeta. Tratan de lo que se ejecuta en el navegador. Para un recorrido paso a paso, consulta nuestra guía práctica sobre el cumplimiento de PCI 6.4.3 y 11.6.1.
¿Me aplican estos requisitos si tengo SAQ A?
Los equipos quedan atrapados aquí. El SAQ A es la autoevaluación más corta, reservada para comercios que externalizan por completo el manejo de los datos del titular de la tarjeta. Es tentador leer "completamente externalizado" como "nada del lado del cliente de qué preocuparse." Ya no es así como el PCI SSC lo trata.
El SAQ A de enero de 2025 eliminó 6.4.3 y 11.6.1 del cuestionario en sí, y luego agregó un nuevo criterio de elegibilidad en su lugar. Para usar el SAQ A ahora tienes que confirmar que tu página de pago no es susceptible a ataques de scripts que pudieran afectar tus sistemas de comercio electrónico, y que cada elemento entregado al navegador proviene directamente de un procesador que cumple con PCI DSS (PCI Security Standards Council, 2025). Los comercios que no puedan hacer esa confirmación quedan fuera del SAQ A y tienen que satisfacer los requisitos de scripts de la página de pago de forma directa. De cualquier manera, el riesgo de scripts del lado del navegador ahora es tu problema. Confirma la versión actual de tu SAQ A y sus criterios de elegibilidad en la Biblioteca de Documentos del PCI SSC antes de asumir que estás fuera de alcance.
El cambio se remonta a un evento específico. El incidente de Polyfill[.]io de 2024 mostró cómo un único script de terceros de confianza, incrustado en más de 490.000 sitios, puede volverse malicioso de la noche a la mañana y servir código de skimming o de redirección a las páginas de checkout (Sansec, 2024). Un comercio con SAQ A usando Stripe Checkout quedó tan expuesto como cualquier otro, porque el script malicioso llegó a través de la propia página del comercio, no de la de Stripe.
Por qué la página de pago sigue siendo tu superficie de ataque
El problema central es dónde se ejecuta el código. El iframe de Stripe aísla los campos de la tarjeta, pero los ataques del lado del cliente rara vez apuntan directamente al campo de la tarjeta. Apuntan a la página que lo rodea.
- Superposiciones de formularios. Un script comprometido puede dibujar un formulario de tarjeta falso encima del iframe de Stripe, o junto a él, y capturar datos antes de que lleguen a Stripe.
- Redirección del checkout. El código inyectado puede enviar a un comprador a una página de pago falsa en medio del flujo.
- Recolección de datos. Un script de analítica o de chat manipulado puede leer nombre, correo electrónico, dirección y detalles del pedido desde el DOM y exfiltrarlos a un dominio controlado por el atacante.
- Debilitamiento de encabezados. Encabezados HTTP que afectan la seguridad, como Content-Security-Policy, al ser modificados pueden abrir la puerta a los scripts anteriores, razón por la cual 11.6.1 nombra los encabezados de forma explícita.
El e-skimming no es un caso extremo poco común. El web skimming estilo Magecart ha golpeado a miles de sitios de comercio electrónico, y la técnica persiste porque el navegador es difícil de monitorear desde el servidor. En el Verizon DBIR de 2024, los datos de tarjetas de pago representaron el 25% de los registros vulnerados en el sector minorista, y el comercio minorista es señalado como el terreno propio de los actores de Magecart que insertan código malicioso en las páginas de checkout (Verizon, 2024). Tanto tus registros del servidor como el panel de Stripe se verán normales mientras un skimmer se ejecuta en los navegadores de tus clientes.
Por eso los requisitos viven en el navegador, no en el backend. Para aprender cómo estos ataques eluden los controles del lado del servidor, consulta nuestra guía de seguridad del lado del cliente.
Cómo satisfacer 6.4.3 y 11.6.1 en la práctica
Puedes cumplir con estos requisitos de forma manual: mantener una hoja de cálculo de cada script, justificar cada uno, calcular su hash y revisar la página de pago renderizada semanalmente en busca de cambios. Para un sitio con un puñado de scripts estáticos, eso podría aguantar. Para un checkout real donde un gestor de etiquetas inyecta scripts de forma dinámica, el enfoque manual se desmorona rápido y produce evidencia en la que los auditores no confían.
La respuesta operativa es el monitoreo continuo y automatizado de scripts, diseñado para la página de pago. cside PCI Shield está diseñado para satisfacer ambos requisitos de forma directa:
- Inventario y justificación automatizados (6.4.3). cside descubre cada script que se ejecuta en tu página de pago, construye el inventario y te permite registrar la autorización y la justificación en un solo lugar, con revisión de un clic y asistida por IA.
- Detección de integridad y de manipulación en tiempo real (11.6.1). cside monitorea los scripts y los encabezados HTTP que afectan la seguridad de forma continua y alerta sobre cambios no autorizados, en lugar de muestrear con un cron semanal y esperar que nada se haya colado entre revisiones.
- Evidencia lista para auditoría. cside archiva cada versión de cada script con su historial completo, para que le entregues a un QSA registros forenses en lugar de suposiciones sobre el comportamiento.
El punto no es reemplazar a Stripe. Stripe y una capa de monitoreo de scripts resuelven mitades distintas del mismo panorama de cumplimiento: Stripe saca los datos de la tarjeta del alcance, y cside cubre los requisitos del lado del navegador que Stripe te deja a ti.
En resumen
Usar Stripe es una forma inteligente de reducir el alcance de PCI, y puede ponerte en el SAQ A. No hace que cumplas por completo con PCI, porque los requisitos 6.4.3 y 11.6.1 te hacen responsable de los scripts y encabezados de tu página de pago, donde los campos alojados de Stripe no tienen alcance. Esos requisitos son obligatorios, y la propia elegibilidad para el SAQ A ahora depende de confirmar que tu página de pago está protegida contra la manipulación de scripts.
Trata la página de pago como tu superficie de ataque, inventaría y autoriza cada script, e implementa detección de manipulación en tiempo real. Para la parte operativa de eso, consulta cside PCI Shield y seguridad del lado del cliente, o agenda una demo para repasar tu checkout.
