Analítica, publicidad, chat, componentes de pago, librerías desde un CDN: la mayoría de los sitios cargan en cada visita código que no han escrito, y ese código se ejecuta con los mismos privilegios que los scripts propios del sitio. Esta guía explica, a partir de fuentes primarias de OWASP y MDN, cómo saber qué se está ejecutando, limitar lo que puede hacer y detectar cuándo cambia. No describe cómo funcionan los ataques.
Por qué los scripts de terceros son un riesgo
La hoja de referencia de OWASP «Third Party JavaScript Management Cheat Sheet» agrupa en tres los riesgos de incrustar JavaScript de terceros.
- Pérdida de control sobre los cambios
- Normalmente no hay garantía de que el código del proveedor siga igual que cuando lo desarrollaste y probaste. El proveedor puede publicar nuevas funciones en cualquier momento
- Ejecución de código arbitrario en los dispositivos
- El código de terceros rara vez se revisa antes de añadirlo y se ejecuta con los mismos privilegios que el usuario. OWASP también describe el caso de un dominio del proveedor que caduca, alguien lo vuelve a registrar y publica código malicioso
- Divulgación de información a terceros
- Al cargar el script, el navegador se conecta directamente con los servidores del proveedor, que recibe la dirección IP y las cookies que haya establecido antes
Un gestor de etiquetas añade otra capa. OWASP explica que lo que devuelve un gestor de etiquetas se puede cambiar desde su interfaz web y se despliega al instante: la siguiente visita ya ejecuta el código modificado. Por eso, leer el código fuente de tu sitio no te dice todo lo que realmente se ejecuta.
Este sitio ha cubierto un caso de este tipo: el incidente del script de terceros en Polymarket. El problema estaba en el código que se ejecutaba en la página que el usuario estaba viendo.
Tu página (contenido, datos de formularios, cookies)
↓ se ejecuta dentro de la misma página
Tus propios scripts
Los revisas y los sirves tú
Scripts de terceros
El proveedor puede cambiarlos. Pueden leer la página
Formularios que envían fuera
Los datos van a otro origen
↓ cómo limitarlos
Inventario y eliminación
SRI / alojamiento propio / CSP script-src y connect-src
CSP form-action
Cómo defenderte: seis pasos
Lista todos los scripts de terceros que se ejecutan
Empieza por un inventario. Incluye los scripts escritos directamente en el HTML, las etiquetas configuradas en el gestor de etiquetas y todo lo que una librería o un plugin carga por su cuenta.
Para cada uno, anota el origen desde el que se carga, de quién es el servicio, por qué se añadió, en qué páginas se ejecuta y quién lo desactiva, y cómo, si algo sale mal. Incluye también iframes, imágenes y otros recursos que se conectan a servidores externos; así la lista sirve directamente para configurar la CSP.
Quita lo que no usas y recorta en las páginas sensibles
Todo lo que en la lista no tenga un propósito conocido o un responsable es candidato a eliminarse. Es habitual que sigan ahí etiquetas de campañas antiguas y servicios de analítica ya sustituidos.
En las páginas donde lo que se escribe es valioso, como el inicio de sesión, el pago, el cambio de contraseña o de correo y el panel de administración, deja solo lo necesario. Una etiqueta puesta en la plantilla común del sitio también llega a estas páginas, así que decide qué se carga según el tipo de página. Para componentes que no necesitan tocar la página, OWASP describe aislarlos en un iframe de otro dominio con el atributo sandbox.
Restringe quién puede publicar en el gestor de etiquetas
OWASP advierte que una capa de datos (el objeto con los valores que se pasan a las etiquetas) no es un entorno aislado y que los contenedores del gestor de etiquetas pueden ejecutar JavaScript y etiquetas HTML personalizadas. Recomienda restringir el acceso de publicación y revisar los cambios como si fueran código de la aplicación.
En la práctica, empieza por cuatro medidas: que solo unas pocas personas puedan publicar, activar la autenticación en dos pasos en las cuentas del gestor, desactivar las etiquetas HTML personalizadas si no las necesitas y que otra persona revise antes de publicar.
Añade SRI a los archivos fijos o sírvelos desde tu sitio
SRI (integridad de subrecursos) permite escribir el hash del archivo en un atributo integrity de <script> y elementos similares; si el archivo que recibe el navegador no coincide, se niega a cargarlo. Según MDN, los hashes permitidos son sha256, sha384 y sha512; un archivo de otro origen requiere que el proveedor permita CORS, y además se añade el atributo crossorigin.
SRI solo funciona con archivos cuyo contenido no cambia, como una librería con versión. En una etiqueta de analítica que el proveedor actualiza cuando quiere, cada actualización rompe la carga. En ese caso, sirve una copia revisada desde tu propio sitio (lo que OWASP llama in-house mirroring) o no la cargues en las páginas sensibles. Para comprobar vulnerabilidades conocidas en las librerías, pega tu lockfile en el Escáner de vulnerabilidades de dependencias.
Restringe orígenes y destinos con CSP
En tu Content-Security-Policy, permite los orígenes de la lista del paso 1. script-src restringe de dónde se cargan los scripts; connect-src restringe a dónde pueden conectarse fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon y APIs similares (MDN).
form-action, que restringe a dónde se envían los formularios, no recurre a default-src. MDN indica que, si no se define, se permite cualquier destino. Si tus formularios solo envían a tu propio sitio, define form-action 'self' de forma explícita.
Aplicar una política nueva de golpe puede romper funciones legítimas, así que primero recoge informes de infracciones con Content-Security-Policy-Report-Only. MDN señala que los informes solo se envían si especificas report-to y que esta cabecera no se admite en un elemento <meta> (la directiva obsoleta report-uri también sigue funcionando). Puedes probar políticas en el Constructor / verificador de CSP; para las cabeceras en general, consulta cómo elegir las cabeceras de seguridad.
Haz visibles los cambios y decide de antemano cómo desactivar scripts
Los scripts de terceros cambian sin que hagas nada. Con una frecuencia fija, por ejemplo cada mes, compara tu lista con lo que realmente se ejecuta e investiga cualquier destino desconocido que aparezca en los informes de infracciones de la CSP. Suscríbete a los avisos de seguridad de los proveedores.
Documenta qué etiqueta se desactiva, quién lo hace y desde qué pantalla cuando algo va mal. Si tienes páginas de pago con tarjeta, ten en cuenta también que los requisitos 6.4.3 y 11.6.1 de PCI DSS v4.0.1 sobre la seguridad de las páginas de pago están en vigor desde el 31 de marzo de 2025 (PCI SSC). Para los comercios que validan con el SAQ A, que externalizan por completo el tratamiento de los datos de tarjeta en terceros que cumplen la norma, esos dos requisitos se sustituyen por un criterio de elegibilidad: confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar a sus sistemas de comercio electrónico; los requisitos de la propia norma no cambian.
Qué evita y qué no evita cada medida
| Medida | Evita | No evita | Adecuada para |
|---|---|---|---|
| Eliminar | Todos los riesgos ligados a ese script | — | Scripts sin propósito conocido o sin uso |
| SRI | La sustitución del archivo en tránsito o en el proveedor | Lo que un script no manipulado envía como parte de su función normal. La carga se rompe cuando el proveedor actualiza el archivo | Archivos fijos con versión |
| Alojamiento propio | La sustitución en el proveedor | Las versiones antiguas se quedan si no las actualizas tú | Librerías revisadas que sigues usando |
| CSP | Cargas desde orígenes no permitidos y solicitudes o envíos de formularios a destinos no permitidos | El compromiso de un origen permitido. Los datos enviados a un destino permitido | Todas las páginas (implantación gradual) |
Fácil de propagarse
- Las etiquetas están en la plantilla común del sitio
- Mucha gente puede publicar en el gestor de etiquetas
- No hay CSP, o no incluye
form-action - No hay lista de scripts de terceros ni una forma acordada de desactivarlos
Bajo control
- Las etiquetas se cargan por tipo de página
- Pocas personas pueden publicar y otra revisa los cambios
- La CSP fija los orígenes de scripts, los destinos de conexión y los de formularios
- Existe una lista y se compara con la realidad de forma periódica
Comprueba el resultado con el Verificador de transparencia del sitio
Con la lista hecha, compárala con lo que hay realmente en la página. Introduce la URL de la página de inicio de un sitio que administres en el Verificador de transparencia del sitio y obtendrás lo siguiente a partir del HTML descargado.
- Orígenes de scripts/recursos externos
- Otros orígenes referenciados por script, iframe, img y link (stylesheet, preload y similares). Todo lo que no esté en tu lista del paso 1 necesita una explicación
- Etiquetas de analítica / anuncios (rastreo)
- Servicios habituales de analítica, publicidad y monitorización, mostrados por nombre. El nombre clasifica el destino; no es un veredicto de seguridad
- Scripts de terceros desconocidos (podrían leer la entrada)
- Scripts cargados desde otro origen. Ningún script se considera seguro porque su proveedor sea conocido
- Formularios que envían al exterior
- Un action de formulario o un formaction de botón que apunta a otro origen. Si no lo pretendías, revísalo primero y fíjalo con CSP form-action
- Establece una cookie
- Si la respuesta descargada incluye Set-Cookie. No se comprueban las cookies que establece JavaScript
La herramienta tiene límites. Solo descarga la página de inicio (incluidas las de cada idioma e index.html), no ejecuta scripts y no descarga archivos incrustados. Los scripts que un gestor de etiquetas carga después y las solicitudes que solo ocurren al pulsar un botón no son visibles. Por eso, haz también lo siguiente.
- Abre la página que quieres comprobar (incluidas las de inicio de sesión y pago) y las herramientas para desarrolladores del navegador
- Graba en la pestaña Network y usa la página con datos ficticios
- Busca solicitudes a dominios externos que no estén en tu lista
- Después de configurar la CSP, confirma con la Verificación de encabezados de seguridad que la cabecera se devuelve de verdad
Si tu sitio opera en Japón: las normas sobre transmisión externa
Según el Ministerio del Interior y Comunicaciones de Japón (MIC), una reforma de junio de 2022 de la Ley de Empresas de Telecomunicaciones introdujo normas para que los usuarios puedan saber cuándo etiquetas o módulos de recogida de datos envían información sobre ellos a terceros (en vigor desde el 16 de junio de 2023). Se aplican a quienes explotan un negocio de telecomunicaciones; el MIC cita como casos principales los servicios de mensajería, las redes sociales, los buscadores y servicios de información como sitios de noticias y agregadores, y señala que la venta en línea de productos propios, los sitios corporativos y los blogs personales no son negocios de telecomunicaciones y quedan fuera.
Cuando se aplican, hay que notificar a los usuarios, o ponerles fácilmente a su alcance, qué información se envía, el nombre de quien la trata y su finalidad. Tu lista del paso 1 es un buen punto de partida para esa información. Consulta la explicación y el diagrama de flujo del MIC para saber si te afecta.
La opinión de este sitio: juzga un script por lo que puede leer en esa página, no por su marca
La revisión de scripts de terceros suele acabar en «es un servicio grande, así que está bien». Pero el riesgo que OWASP sitúa en primer lugar es el compromiso del servidor del proveedor, y un servicio muy usado está en muchísimos sitios, de modo que un compromiso ahí se extiende mucho.
Por eso nuestro Verificador de transparencia del sitio nunca marca un script como seguro porque su proveedor sea famoso. Las preguntas que importan son en qué páginas se ejecuta, qué puede leer allí y cuántos minutos tardarías en desactivarlo.
Fuentes (primarias)
- OWASP, «Third Party JavaScript Management Cheat Sheet» — cheatsheetseries.owasp.org (los tres riesgos, gestores de etiquetas, SRI, aislamiento en iframe, in-house mirroring)
- MDN, «Subresource Integrity» — developer.mozilla.org (atributo integrity, hashes permitidos, CORS y el atributo crossorigin)
- MDN, «Content Security Policy (CSP)» — developer.mozilla.org (script-src, pruebas en modo report-only)
- MDN, «CSP: form-action» — developer.mozilla.org (sin respaldo en default-src)
- MDN, «CSP: connect-src» — developer.mozilla.org (las APIs que cubre)
- MDN, «Content-Security-Policy-Report-Only» — developer.mozilla.org (requiere report-to; no se admite en meta)
- PCI SSC, «Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A» (30 de enero de 2025) — blog.pcisecuritystandards.org (requisitos 6.4.3 y 11.6.1 en vigor desde el 31 de marzo de 2025)
- MIC (Japón), «外部送信規律» (en japonés) — soumu.go.jp (finalidad, ámbito y qué se debe informar)
Para seguir leyendo
- Herramientas: Verificador de transparencia del sitio / Constructor / verificador de CSP / Verificación de encabezados de seguridad
- Configuración: Cómo elegir las cabeceras de seguridad
- Incidentes: El incidente del script de terceros en Polymarket
- Glosario: qué es XSS / qué es PCI DSS