¿Qué es Subresource Integrity (SRI)? Guía para sitios WordPress

Subresource Integrity (SRI) es un estándar de seguridad del W3C que te permite especificar un hash criptográfico en etiquetas <script> y <link> para que el navegador pueda verificar que el archivo cargado coincide con lo que esperas. Si el archivo en la URL ha sido modificado, interceptado o reemplazado (ya sea por un atacante, un CDN comprometido, o incluso una actualización accidental), el navegador bloquea la ejecución por completo. SRI se estandarizó en 2016 y está soportado por todos los navegadores principales. Es una de las mitigaciones más baratas contra ataques de cadena de suministro a JavaScript de terceros, que es la fuente dominante de incidentes de brechas en sitios WordPress en 2026.

¿Cómo se ve un hash SRI y cómo lo añado?

Una etiqueta script con SRI habilitado tiene dos atributos extra: integrity y crossorigin:

<script
  src="https://cdn.example.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous">
</script>

El valor integrity es un hash criptográfico codificado en base64 del contenido del archivo, con el algoritmo usado como prefijo (sha256-, sha384- o sha512-). SHA-384 es la elección recomendada en 2026: un buen equilibrio entre seguridad y longitud del hash. SHA-512 también es aceptable. SHA-256 sigue funcionando pero se considera el más débil de los tres; está bien para assets no críticos pero no para nada sensible en seguridad.

Cuando el navegador carga el archivo, calcula su hash y lo compara con el valor integrity. Si los hashes coinciden, el script se ejecuta. Si difieren aunque sea en un byte, el navegador se niega a ejecutarlo y registra un error en la consola.

¿Qué ataques previene Subresource Integrity?

SRI protege específicamente contra el caso en el que un archivo de terceros se modifica entre el momento en que decidiste confiar en él y el momento en que el navegador del usuario realmente lo carga. Los tres escenarios más relevantes para sitios WordPress:

• Compromiso del CDN. Si un atacante irrumpe en un CDN (o en el servicio de terceros cuyo CDN usas) y modifica un archivo JavaScript, cada sitio que embeba ese archivo vía <script src> ejecutaría de repente el código del atacante. SRI lo detecta inmediatamente: el archivo modificado no coincide con el hash, el navegador lo bloquea.
• Toma de control de cuenta en el proveedor de terceros. Alguien compromete una cuenta de analytics, widget de chat o hosting de fuentes y publica una actualización maliciosa al script que has embebido. Sin SRI, tu sitio ejecuta la actualización maliciosa en cada carga de página. Con SRI, el script falla silenciosamente hasta que actualices el hash, lo cual significa hasta que hayas verificado personalmente la nueva versión.
• Manipulación a nivel de red. Un atacante man-in-the-middle en una red corporativa o WiFi hostil reescribe un archivo JavaScript mientras está en tránsito hacia el usuario. HTTPS previene esto para conexiones directas a tu origen, pero un script de terceros servido desde un intento de envenenamiento DNS controlado por el atacante podría eludirlo. SRI proporciona una verificación de integridad de extremo a extremo independiente de TLS.

La brecha de British Airways de 2018 donde 380.000 clientes tuvieron sus datos de pago robados ocurrió porque el atacante modificó un script Modernizr de terceros que BA cargaba en su página de checkout. SRI en esa etiqueta script habría detenido el ataque en el momento en que se cargó el archivo modificado. Siguen ocurriendo incidentes similares, con ataques tipo Magecart sobre sitios de e-commerce como la categoría más documentada.

¿A qué archivos debería añadir SRI?

SRI es para archivos de terceros cargados por la red. Tres categorías importan, en orden de prioridad:

• Flujos de pago, checkout y login. Cualquier JavaScript que se ejecute en una página donde los usuarios introducen tarjetas, contraseñas u otros datos sensibles es el objetivo de mayor prioridad. Un script comprometido en una página de checkout es el peor escenario. Si tu checkout WooCommerce carga algo desde un CDN, cada uno de esos scripts debería tener SRI.
• Scripts embebidos globalmente. Cualquier cosa en <head> o cerca del inicio de <body> que se ejecuta en cada página: etiquetas de analytics, fuentes, polyfills, jQuery desde un CDN público. Estos se ejecutan antes de que el usuario tenga oportunidad de notar nada raro.
• Scripts CDN inyectados por plugins. Muchos plugins WordPress (widgets de chat, A/B testing, píxeles de marketing) cargan JavaScript remoto. Estos están escritos por terceros en los que has confiado implícitamente, y normalmente no incluyen SRI por defecto.

Por el contrario, no añadas SRI a archivos servidos desde tu propio dominio. Si un atacante tiene acceso para modificar archivos en tu servidor de origen, también puede modificar el HTML que declara el hash, así que SRI no aporta protección real. SRI brilla solo para recursos cross-origin.

¿Cómo genero un hash SRI para un script de terceros?

Tres métodos prácticos:

1. Usa srihash.org. Herramienta web. Pega la URL del script, obtén la etiqueta <script> completa con los atributos integrity y crossorigin. La vía más rápida para añadidos puntuales.
2. OpenSSL desde la línea de comandos. curl -s https://cdn.example.com/file.js | openssl dgst -sha384 -binary | openssl base64 -A emite el hash base64 al que antepones sha384-. Útil al hacer scripts o trabajar con archivos localmente antes del despliegue.
3. Mira la documentación del proveedor. CDNs principales (cdnjs.com, jsDelivr) publican el hash SRI junto a cada versión de cada librería que hospedan. Bootstrap, jQuery, Vue, React, etc. publican el valor integrity recomendado en sus páginas oficiales de getting-started. Copia y pega desde allí.

Una advertencia: el hash está atado al contenido exacto en bytes del archivo. Si el CDN sirve una versión diferente (porque usaste una URL como jquery@3 en lugar de jquery@3.7.1), el hash no coincidirá y el script se bloqueará. Cuando uses SRI, fija siempre versiones específicas.

¿Por qué se requiere el atributo crossorigin="anonymous"?

El atributo crossorigin="anonymous" le dice al navegador que recoja el archivo de terceros usando CORS, sin enviar cookies ni autenticación. Sin él, el navegador no puede leer el cuerpo de respuesta del archivo para calcular su hash (un detalle de la política same-origin), y la verificación SRI falla silenciosamente abierta: el script se ejecuta sin ser comprobado.

Este es el error SRI más común. La gente añade integrity pero olvida crossorigin, y luego asume que su configuración funciona porque el script sigue cargando. Sin ambos atributos, no tienes protección real. Para verificar: abre DevTools, pestaña Network, haz clic en el script, mira la respuesta. Si el CDN soporta CORS (esencialmente todos los CDNs públicos modernos lo hacen), verás Access-Control-Allow-Origin: * en las cabeceras de respuesta. Sin esa cabecera, SRI no puede funcionar en ese recurso en absoluto.

¿Cómo añado SRI a WordPress?

Tres escenarios dependiendo de cómo lleguen los scripts a tus páginas:

Escenario 1: scripts encolados por WordPress (tema o plugin)

El core de WordPress soporta SRI vía el filtro script_loader_tag. Añade al functions.php de tu child theme o a un pequeño mu-plugin:

add_filter('script_loader_tag', function ($tag, $handle, $src) {
    $sri_hashes = [
        'jquery'    => 'sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs',
        'bootstrap' => 'sha384-...tu-hash-aqui...',
    ];

    if (isset($sri_hashes[$handle]) && strpos($src, '://') !== false && strpos($src, home_url()) === false) {
        $tag = str_replace(
            ' src=',
            ' integrity="' . $sri_hashes[$handle] . '" crossorigin="anonymous" src=',
            $tag
        );
    }
    return $tag;
}, 10, 3);

Ajusta los nombres de handle y los hashes para que coincidan con tus scripts. Las comprobaciones strpos garantizan que SRI solo se aplica a scripts cargados desde dominios externos, no los tuyos.

Escenario 2: scripts hardcodeados en plantillas del tema

Si un tema emite directamente etiquetas <script src="https://..."> en header.php u otro lugar, edita esas etiquetas directamente para añadir los atributos integrity y crossorigin. Refleja esto en tu child theme para sobrevivir actualizaciones del tema padre.

Escenario 3: scripts inyectados por JavaScript o plugins de terceros en tiempo de ejecución

Widgets de chat, herramientas de A/B testing y gestores de etiquetas a menudo inyectan etiquetas script dinámicamente. SRI sigue funcionando en este caso: el elemento <script> creado dinámicamente debe establecer las propiedades integrity y crossOrigin antes de que el script sea añadido al DOM. La mayoría de las versiones enterprise de estas herramientas lo soportan vía configuración; los tiers gratuitos normalmente no. Para inyecciones de terceros no gestionadas, el fallback práctico es una Content Security Policy con require-sri-for script (aún en borrador) o simplemente auditoría cuidadosa.

¿Cuál es la carga de mantenimiento de SRI?

Este es el trade-off honesto. SRI es un compromiso entre seguridad y comodidad. Cada vez que la librería upstream se actualiza, el hash cambia, tu script se rompe, y tienes que actualizar el hash. Para un sitio estable que fija versiones y rara vez las actualiza, esta es una tarea trimestral. Para un sitio que usa jquery@latest o depende de CDNs con auto-actualización, SRI es una fuente constante de rupturas.

Tres patrones que hacen manejable el mantenimiento de SRI:

• Fija versiones específicas, no "latest". URL como https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js, no jquery@latest. El hash es entonces estable hasta que deliberadamente actualices.
• Usa un CDN que publique hashes. Tanto cdnjs como jsDelivr publican el hash SRI para cada archivo. Actualizar el hash cuando actualizas es una tarea de 30 segundos.
• Auto-aloja librerías críticas. Una vez auto-alojes (lo cual deberías considerar por razones GDPR de todos modos, ver la discusión sobre Google Fonts), SRI se vuelve irrelevante para ese script. SRI es para casos en los que no puedes auto-alojar. Para analytics, fuentes, librerías usadas en una página, el auto-hosting es a menudo la mejor respuesta.

Errores comunes

• Olvidar crossorigin="anonymous". El script sigue cargando pero ya no se verifica su integridad. El fallo SRI silencioso más común.
• Usar SRI en recursos same-origin. Un atacante que pueda modificar tu /wp-includes/js/jquery.js también puede modificar el HTML que declara el hash. Usa SRI solo en recursos cross-origin.
• Calcular el hash sobre la versión equivocada del archivo. El hash debe coincidir con los bytes exactos que el navegador recibirá, incluyendo cualquier minificación o transformación del lado del CDN. Recoge siempre desde la URL real de producción al calcular.
• No actualizar el hash al actualizar la librería. Actualizas la versión de la librería en la URL, olvidas actualizar integrity, el script silenciosamente deja de funcionar. Síntomas: una funcionalidad se rompe, la consola muestra "Failed to find a valid digest in the integrity attribute".
• Usar SHA-1. SHA-1 es vulnerable a colisiones y ha sido deprecado para SRI. Usa SHA-384 o SHA-512.
• Intentar usar SRI en un CDN sin CORS. El navegador no puede calcular el hash, así que SRI es imposible. O el CDN debe habilitar CORS, o tienes que auto-alojar el archivo.

SRI y Content Security Policy (CSP)

SRI y CSP son complementarios, no redundantes. CSP dice "solo se permiten ejecutar scripts de esta lista de orígenes". SRI dice "y ese script debe coincidir con este hash exacto". Juntos forman un enfoque de defensa en profundidad: CSP bloquea orígenes desconocidos; SRI bloquea manipulación en orígenes conocidos. Una CSP con script-src 'self' https://trusted-cdn.com dice "confiamos en trusted-cdn.com"; añadir hashes SRI a tus scripts en trusted-cdn.com reduce esa confianza a versiones específicas del archivo.

La directiva CSP en borrador require-sri-for script forzaría que cada script cross-origin debe tener un atributo integrity, a nivel de navegador. A 2026 tiene soporte limitado pero es la dirección hacia donde se mueve el estándar.

Qué verifica InspectWP

La sección de Seguridad de cada reporte InspectWP inspecciona etiquetas de script y stylesheet externas y reporta cuáles incluyen atributos integrity y cuáles no. La ausencia de SRI en un script desde un CDN de terceros se marca como hallazgo de severidad baja a media, según el contexto. Una página de login o checkout cargando JavaScript externo sin SRI es una advertencia de mayor prioridad. El reporte también marca valores integrity mal formados (prefijo de algoritmo incorrecto, base64 inválido) que pueden dar una falsa sensación de protección mientras son realmente ignorados por el navegador. SRI es una de esas medidas donde la existencia del atributo importa menos que su corrección; un hash erróneo es funcionalmente equivalente a no tener hash porque el navegador sigue rechazando incoincidencias, pero un atributo crossorigin ausente hace toda la verificación silenciosa.