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 y qué se espera de las organizaciones?
Por Qué la Integridad de Scripts Importa para Comercios y Empresas de E-commerce
Los recursos obtenidos de terceros provienen de fuentes externas. Confiar incondicionalmente en una fuente no es seguro en el entorno cambiante de internet. Las empresas SaaS aparecen y desaparecen, y lamentablemente muchas no tienen un plan de contingencia para los dominios que 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 comenzar con un punto de entrada bastante mundano (como un dominio expirado) que le da a los atacantes una apertura 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 ser recopilados mediante iframes inyectados sobre elementos de pago (web skimming), cadenas de redirección forzada, secuestro de cookies de afiliados, entrega de malware a nivel de dispositivo o incluso 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 en 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 ataques que afectaron a más de 380.000 sitios web en 2025 (Informe de Ataques del Lado del Cliente 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 esperado.
Qué es la Integridad de Scripts
Conceptos Erróneos sobre el Término
Es probable que el término "integridad de scripts" se use como resultado del priming léxico asociado 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 encontrado recientemente; algo que todos hacemos.
Sin embargo, usar la palabra "integridad" de forma aislada puede generar confusión y está sujeta 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 dificulta enormemente 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, comenzaran a comportarse de forma dinámica de repente. Ejemplo: jQuery versión x.
En esencia, SRI aborda el "factor de cambio" verificando que el contenido de un script sea 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, por lo que disponer de 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: considerar la adición de hashes a la especificación.
Durante un tiempo, CSP solo confiaba en las fuentes, lo que generó el siguiente problema. Imagina que llegan 2 paquetes a tu puerta. Ambos del mismo remitente, pero uno contiene un cachorro adorable y el otro una bomba de purpurina.
¿Puedes saber 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 razonable 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
Para garantizar 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 invalidar 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 diferente mediante otros protocolos de seguridad, como un motor de inspección de scripts basado en IA.
Las Herramientas de Escaneo No Pueden Verificar la Integridad de Scripts
Los scripts del lado del cliente responden de forma diferente 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 diferente del servidor. No es raro que un script del lado del cliente sirva contenidos distintos 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 el payload malicioso a un subconjunto específico 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.
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 participado. 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 asumir. 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 interpreta de forma diferente 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 requiere un mantenimiento continuo a medida que los atacantes cambian sus técnicas.
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 sean estándares de privacidad como GDPR y CCPA, o estándares de seguridad orientados a combatir scripts maliciosos como PCI DSS 4.0.1, ISO 27001 e 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 al equipo para presionar a los organismos del sector a fin de que permitan 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: proteger a nuestros amigos y familiares de la ansiedad por la seguridad en línea y evitar que los comercios tengan que subir precios para compensar el fraude.
