Resumen: hashes SRI para scripts terceros dinámicos
- SRI fija archivos estáticos: SRI ata un hash a un archivo estático. Los terceros modernos entregan código que cambia en cada carga. Los comercios cargan docenas por checkout. Fijar lo que no se queda quieto es una casilla de cumplimiento, no un control.
- La trazabilidad: Mastercard señala el e-skimming como la principal fuente de skimming de tarjetas y el Client-side Attack Report de cside contó más de 380.000 sitios afectados en 2025. cside genera hashes SRI para los scripts estáticos, vigila el comportamiento de los dinámicos y te da la trazabilidad que realmente piden PCI DSS 6.4.3 y 11.6.1.
- SRI es una capa: No trates SRI como la meta, trátalo como una capa. Si tu historia de integridad termina en hashes, un dominio de proveedor caducado o un pipeline CI/CD secuestrado sigue permitiendo a un atacante reescribir el comportamiento de pago dentro del navegador el próximo martes.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
El término "integridad de scripts" aparece en requisitos de cumplimiento como PCI DSS 4.0.1, ISO 27001, HIPAA y otros marcos normativos, pero ¿qué significa exactamente este término y qué se espera?
Por Qué la Integridad de Scripts Importa para Comercios y Empresas de E-commerce
Los recursos obtenidos de terceros provienen de una fuente externa. Confiar incondicionalmente en una fuente no es seguro en el entorno tan cambiante de internet. Las empresas SaaS aparecen y desaparecen, y lamentablemente muchas no tienen un plan de contingencia para los dominios que se usaban en los entornos de producción de sus clientes.
En el pasado se han producido una serie de incidentes que afectaron a consumidores desprevenidos en todo el mundo.
Las inyecciones mediante el secuestro de una fuente de terceros pueden realizarse de varias formas.
- Ingeniería social
- Secuestros dirigidos a CI/CD
- Dependencias de código abierto maliciosas
- Inyecciones de malware a nivel de máquina en los dispositivos de los desarrolladores
- Apropiación de un dominio expirado
No tiene por qué ser un ataque sofisticado a la cadena de suministro; puede empezar con un punto de entrada bastante mundano (como un dominio expirado) que le da a los atacantes una vía de acceso silenciosa para manipular el código que se ejecuta en tu sitio sin que nadie lo note.
La próxima vez que tus usuarios introduzcan información en tus páginas, los datos sensibles pueden recopilarse mediante iframes inyectados sobre los elementos de pago (web skimming), cadenas de redirección forzada, secuestro de cookies de afiliados, entrega de malware a nivel de dispositivo o incluso la explotación de vulnerabilidades zero-day en el navegador.
Integridad de Scripts: Para el Cumplimiento Normativo
Los marcos de cumplimiento exigen cada vez más que las empresas supervisen la integridad y el historial de cambios de los scripts del lado del cliente.
- Para PCI DSS 4.0.1: la validación de la integridad de scripts es necesaria para cumplir los requisitos de detección de cambios de 6.4.3 y 11.6.1 (Cómo cumplir con PCI DSS 6.4.3 y 11.6.1)
Integridad de Scripts: Para Prevenir Ataques del Lado del Cliente
Según Mastercard, la principal fuente de robo de datos de tarjetas de crédito es el e-skimming, que ocurre en el lado del cliente. Los scripts comprometidos son una puerta abierta para que los atacantes lleven a cabo:
- Formjacking, ataques Magecart, web skimming, redirecciones maliciosas para phishing y otros tipos de ataque que afectaron a más de 380.000 sitios web en 2025 (Client-side Attack Report 2025).
Gestión de la Integridad de Scripts: Para Empresas de E-commerce
Cualquier comercio que procese un alto volumen de transacciones en línea es un objetivo prioritario para la explotación del lado del cliente.
- Los sitios de e-commerce modernos incorporan decenas de scripts de terceros. Los comercios necesitan visibilidad sobre qué hacen esos scripts, cuándo cambian y si esos cambios se corresponden con el comportamiento previsto.
Qué es la Integridad de Scripts
Conceptos Erróneos sobre el Término
Es probable que el término "integridad de scripts" se use por priming léxico respecto al método de gestión "Subresource Integrity" referenciado en los principales marcos de cumplimiento. El priming léxico consiste en reutilizar palabras que hemos visto recientemente; algo que todos hacemos.
Sin embargo, usar la palabra "integridad" de forma aislada puede generar confusión y está abierta a interpretación.
¿Qué Hace que un Script Tenga (o Carezca de) Integridad?
Monitoreo del Comportamiento para la Integridad de Scripts
En este contexto, integridad puede significar "asegurarse de que los scripts no se comporten de forma maliciosa". El problema es que la exfiltración de datos por sí sola no es un comportamiento malicioso, ni tampoco lo es una redirección. Muchos scripts de terceros hacen esto por razones legítimas, lo que hace muy difícil controlar los cambios.
Monitoreo de Cambios en Scripts para la Integridad de Scripts
El factor de cambio es al que los marcos de cumplimiento hacen referencia con más frecuencia: garantizar que, cuando un script cambia, esos cambios se correspondan con el uso esperado del script.
¿Qué es Subresource Integrity (SRI)?
Subresource Integrity (SRI) es una herramienta de seguridad nativa del navegador que permite al propietario de un sitio web añadir un hash a una directiva de script en una aplicación web. SRI existe desde 2015, cuando Google y Mozilla lo adoptaron en sus navegadores, y fue reconocido posteriormente por el w3c en 2016.
Propósito de Subresource Integrity (SRI)
El objetivo de SRI era evitar que los recursos estáticos obtenidos del lado del cliente, como los activos versionados, empezaran a comportarse de repente de forma dinámica. Ejemplo: jQuery versión x.
SRI aborda el "factor de cambio" verificando que el contenido de un script permanezca idéntico a su versión conocida y de confianza.
Por Qué se Añadió SRI a CSP
Con el tiempo, cada vez más funcionalidades de SRI se fueron incorporando a las Content Security Policies (CSP). Esto planteó la pregunta: ¿por qué tener ambas? La seguridad se basa en capas, así que tener opciones es positivo. Sin embargo, la limitación de CSP de no interactuar activamente con el contenido de los scripts llevó al siguiente paso lógico: plantearse añadir hashes a la especificación.
Durante un tiempo CSP solo confiaba en las fuentes, y esto generó el siguiente problema. Imagina que llegan 2 cajas a tu puerta. Ambas del mismo remitente, pero una contiene un cachorro adorable y la otra una bomba de purpurina.
¿Puedes decir, por la dirección del remitente, cuál es cuál?
El argumento aquí es: no confíes en las fuentes, verifica el contenido que sirven. Es justo decir que, una vez que un contenido malicioso proviene de una fuente, esa fuente ya no se considera de confianza. Pero para que eso sea accionable, aún necesitas comprobar qué hace la fuente.
Subresource Integrity Falla en la Web Dinámica Actual
Con el fin de lograr contenidos predecibles en los scripts, SRI ha supuesto un gran avance. Subresource Integrity es eficaz para scripts estáticos y versionados, pero falla con los scripts dinámicos.
La mayoría de los scripts obtenidos del lado del cliente en 2025 son dinámicos, y con razón. Adaptan el contenido según la ubicación geográfica del usuario, el tipo de dispositivo, las características del navegador o los requisitos de personalización. Cualquiera de estos cambios legítimos podría romper el hash utilizado por SRI.
Combinar SRI con una Herramienta de Monitoreo de Scripts Dinámicos
Con cside, SRI puede aplicarse de forma más efectiva. cside detecta scripts estáticos y te ayuda a generar las cabeceras SRI correspondientes. Los scripts dinámicos se gestionan de forma distinta mediante otros protocolos de seguridad, como un motor de inspección de scripts impulsado por IA.
Las Herramientas de Escaneo No Pueden Verificar la Integridad de Scripts
Los scripts del lado del cliente sirven contenido de forma distinta según el User Agent, la IP de la solicitud, el país, la hora del día, etc.: cualquier elemento dentro de una cabecera de solicitud puede generar una respuesta distinta del servidor. No es raro que un script del lado del cliente sirva contenidos diferentes de forma aleatoria.
Debido a esta variabilidad, los enfoques basados en escáneres no son un método fiable para verificar la integridad de los scripts. Los atacantes pueden detectar fácilmente cuándo un rastreador o una herramienta automatizada está solicitando el archivo. Simplemente sirven una versión limpia al escáner y entregan la carga maliciosa a un subconjunto concreto de usuarios reales.
Actualizaciones de Subresource Integrity
Desde el lanzamiento inicial de SRI se han realizado diversas mejoras. Una preocupación habitual con SRI era que, si el hash de un script no coincidía, el script quedaba bloqueado pero no había ninguna API de reporte disponible, lo que resultaba en una página rota sin ninguna alerta para el propietario del sitio web.
Sin embargo, con la especificación actualizada de Integrity Policy esto ya es posible.
cside contribuye a las mejoras de SRI
Se están proponiendo más especificaciones para SRI, en las que cside ha contribuido. Como miembro activo del w3c (la principal organización que desarrolla estándares para la web), cside ha presentado propuestas para mejorar las especificaciones de gestión dinámica de hashes de scripts.
En su estado actual, los hashes de scripts codificados de forma fija conllevan desafíos que la mayoría de las empresas no pueden permitirse. Hasta entonces, SRI puede ser una herramienta útil para scripts estáticos o predecibles, pero no es la solución completa para garantizar la integridad de los scripts.
Cómo Verificar la Integridad de Scripts para el Cumplimiento Normativo
Usar una Herramienta de Seguridad del Lado del Cliente
Aunque la definición exacta de "integridad de scripts" se interprete de forma distinta según el marco normativo, hay un punto en el que existe amplio consenso: las herramientas de proveedores ya desarrolladas son el camino más práctico para verificar la integridad de los scripts. Construir estas capacidades internamente llevaría meses y requeriría un mantenimiento continuo a medida que los atacantes cambian de técnica.
Durante nuestro reciente webinar con BARR Advisory, el consultor de cumplimiento Kyle Kofsky lo expresó con claridad: la recomendación por defecto para las organizaciones que abordan los requisitos de integridad de scripts de PCI DSS 6.4.3 y 11.6.1 es adoptar una solución de proveedor validada.
Usar cside para Verificar la Integridad de Scripts
Con la solución de seguridad de scripts de cside, simplemente añades un script a tu sitio web y nosotros monitoreamos el comportamiento de cada script en tu sitio. Obtienes un panel de control para entender a qué datos accede cada script, a dónde envía esos datos, cómo han evolucionado esos comportamientos a lo largo del tiempo, así como el origen del script y si se pueden realizar mejoras de rendimiento.
Esta información se documenta automáticamente en el formato requerido para tus obligaciones de cumplimiento. Ya se trate de estándares de privacidad como GDPR o CCPA, o de estándares de seguridad orientados a combatir scripts maliciosos como PCI DSS 4.0.1, ISO 27001 y HIPAA, nuestra solución cumple y supera estos requisitos, y está validada por los evaluadores de primer nivel del sector. Consulta nuestro White Paper con Vikingcloud aquí.
cside quiere hacer la web más segura. Al usar nuestra solución, empoderas a tu equipo para presionar a los organismos del sector y conseguir mecanismos de seguridad más sencillos y robustos en los navegadores. Somos transparentes sobre las limitaciones y trabajamos para hacer el mundo más seguro. Nuestra motivación: evitar que nuestros amigos y familiares sufran ansiedad por la seguridad en línea, y evitar que los comercios tengan que subir precios para compensar el fraude.
