SRI

SRI (Subresource Integrity, Integridad de Subrecursos) es una característica de HTML5 que permite fijar el hash SHA-256/SHA-384/SHA-512 de un recurso externo. El navegador calcula el hash al descargar y se niega a ejecutar el recurso si los hashes no coinciden.

Ejemplo: <script src="https://cdn.example/lib.js" integrity="sha384-AbC..." crossorigin="anonymous"></script>

Contra qué protege: un compromiso de CDN. Si un atacante toma el control del CDN y sirve JavaScript modificado, cada sitio que incluya el script mediante SRI se negará a ejecutar la versión modificada. Sin SRI, cada sitio recibe silenciosamente la carga maliciosa.

La compensación: fijar un hash significa que no se puede actualizar el recurso sin actualizar cada página que lo referencia. Para activos propios que se construyen de todos modos, SRI es una defensa de bajo coste. Para scripts de CDN de terceros (jQuery, etiquetas de análisis) es una mejora de seguridad significativa a costa de una propagación de actualizaciones más lenta.

SRI requiere crossorigin="anonymous" en la etiqueta más un encabezado CORS en la respuesta del CDN — el navegador necesita poder leer la respuesta de forma opaca.

Incidentes reales que SRI habría detenido: la familia de ataques Magecart de robo de tarjetas comprometió repetidamente JavaScript de terceros alojado por proveedores de confianza (BrowserAloud, Inbenta, Picreel) e inyectó código ladrón de tarjetas que se cargaba en miles de páginas de pago de comercio electrónico. La brecha de Ticketmaster en 2018 y la de British Airways en 2018 involucraron a atacantes modificando scripts en hosts que los sitios afectados incluían mediante <script src="…">. SRI es la mitigación específica: si esos sitios hubieran fijado el hash de integridad de la versión del script que pretendían cargar, la carga modificada habría fallado la verificación y el navegador se habría negado a ejecutarla.

Cómo generar y rotar hashes SRI de forma pragmática: para archivos propios, el pipeline de construcción debería emitir hashes SRI junto al paquete de activos e incluirlos en el HTML en tiempo de plantilla (Next.js, Vite y Webpack admiten esto con plugins). Para bibliotecas de terceros, el flujo de trabajo recomendado es bloquear a una versión específica, copiar el archivo a su propio CDN y fijar el SRI de eso — depender del CDN upstream para mantener los mismos bytes disponibles en la misma URL es arriesgado con el tiempo. El atributo integrity acepta múltiples hashes separados por espacios, permitiendo transiciones de algoritmo hash (distribuir SHA-384 y SHA-512 juntos; el navegador elige el que admite). Relacionado: CSP, SHA-256. Referencia: W3C — Integridad de Subrecursos.

Ejemplo práctico

Quiere incluir jQuery 3.7.1 desde un CDN con protección SRI. Calcule el hash SHA-384 del archivo: openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A produce algo como Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc. Incrústelo: <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha384-Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc" crossorigin="anonymous"></script>. Al cargar la página, el navegador descarga el archivo, calcula su SHA-384, lo codifica en base64 y lo compara con el atributo integrity. Si el CDN sirve un archivo manipulado — incluso un cambio de un solo byte — los hashes divergen, el navegador bloquea la ejecución y aparece un SecurityError en DevTools. La página sigue renderizándose; solo se suprime el script que falló la integridad.

Cuándo y por qué importa

Cada vez que su sitio carga JavaScript desde un dominio que no controla, está confiando en los operadores de ese dominio, su proveedor de CDN, su DNS y cada paso de TLS entre medias. Esa confianza se deposita mal empíricamente con suficiente frecuencia como para importar: los compromisos de cadena de suministro que afectan a paquetes npm, plugins de jQuery, contenedores GTM y scripts de análisis han afectado a sitios importantes a un ritmo de varios por año. SRI es la defensa que no requiere confiar en el tercero. La estrategia de despliegue pragmática: fijar SRI en scripts de terceros que carga por URL (bibliotecas alojadas en CDN, widgets integrados), pero no en scripts que empaqueta y distribuye desde su propio origen donde controla los bytes. Combinar con CSP require-sri-for script (propuesto pero aún no ampliamente implementado) o script-src con hashes permitidos explícitos para defensa en profundidad. Referencia: MDN — Integridad de Subrecursos.