Per què això importa més del que sembla

Obre el web de la teva empresa, prem F12 i entra a la pestanya «Xarxa» (Network). Torna a carregar la pàgina i fixa’t en quants dominis que no són teus apareixen a la llista.

Analítica, píxels de LinkedIn i de Google Ads, el CRM, el xat, el mapa de calor, el formulari incrustat, el vídeo, l’eina de proves A/B. En molts webs de màrqueting B2B, la llista és força més llarga del que el mateix equip s’imagina.

Cadascun d’aquests dominis executa codi dins del navegador dels teus visitants, sota la teva marca. I gairebé cap no ha passat per una revisió de seguretat.

Aquest és el risc oblidat. En aquest article veiem com funciona, com s’ha explotat a la pràctica i quins controls pots aplicar sense convertir l’equip de seguretat en el departament que sempre diu que no.

Què són els scripts de tercers i per què un gestor d’etiquetes els multiplica

Un script de tercers és qualsevol fragment de JavaScript que el teu web carrega des d’un servidor que no controles: una biblioteca allotjada en una CDN, el codi d’un píxel publicitari o un giny de xat. Quan el navegador el rep, l’executa com si fos codi teu.

Un gestor d’etiquetes, com ara Google Tag Manager, hi afegeix una altra capa. Instal·les un únic fragment al web i, a partir d’aquí, l’equip de màrqueting publica etiquetes des d’una interfície web, sense passar per desenvolupament ni per un desplegament. Aquesta agilitat és justament el que es busca, i també és el que canvia el model de risc.

Amb un gestor d’etiquetes, la llista de scripts que s’executen al teu web deixa de ser al repositori de codi. És en un compte extern, la pot modificar qualsevol persona amb permisos de publicació i pot incloure etiquetes d’«HTML personalitzat», que no són res més que JavaScript arbitrari.

La guia d’OWASP sobre gestió de JavaScript de tercers resumeix bé el problema. Identifica tres riscos principals: la pèrdua de control sobre els canvis en l’aplicació client, l’execució de codi arbitrari als dispositius dels usuaris i la filtració d’informació a tercers. També assenyala que el risc més gran és que es comprometi el servidor del proveïdor i s’injecti codi maliciós a l’script original.

Per què un script de màrqueting és un objectiu atractiu

Un atacant no necessita entrar al teu servidor si pot entrar al d’un proveïdor que ja és dins del teu web. Hi ha tres raons per les quals aquesta via resulta tan rendible.

Té els mateixos privilegis que el teu propi codi

Un script de tercers pot llegir el que l’usuari escriu en un formulari, modificar el contingut de la pàgina, afegir camps falsos, llegir les galetes que no estiguin marcades com a HttpOnly i redirigir el visitant a una altra adreça. El navegador no distingeix entre «codi de casa» i «codi d’un proveïdor».

Ningú no el revisa com revisa el seu propi codi

El codi propi passa per revisions, proves i, amb sort, alguna prova de penetració. El de tercers s’incorpora amb un copiar i enganxar i es dona per bo. A més, pot canviar sense que facis res: el proveïdor actualitza el fitxer i el teu web comença a executar la versió nova aquella mateixa tarda.

L’efecte multiplicador afavoreix l’atacant

Si algú compromet un proveïdor popular, compromet de cop tots els webs que carreguen el seu script. És més eficient que atacar llocs web un per un. Per això els scripts de tercers són un objectiu habitual dels grups que roben dades de pagament directament des del navegador, coneguts en conjunt com a Magecart.

Quatre maneres com es trenca la cadena

1. El proveïdor pateix una intrusió

El 2018, l’script d’un proveïdor de xatbot que Ticketmaster utilitzava al seu web es va manipular per capturar les dades de pagament dels clients. El punt feble no era als servidors de l’empresa, sinó en un component extern que ningú no vigilava com a codi propi.

2. El domini canvia de mans

Un script que avui és legítim pot deixar de ser-ho demà sense que canviï ni una sola línia del teu web. N’hi ha prou que el domini que el serveix caduqui o es vengui. OWASP ja advertia d’aquest escenari.

El cas més clar és el de Polyfill.io. A principis de 2024, el domini i el servei van passar a mans d’una empresa xinesa de CDN anomenada Funnull, i més endavant l’script servit va començar a injectar codi maliciós. Segons SecurityWeek, més de 100.000 webs carregaven aquell domini, i l’autor original del projecte havia recomanat deixar d’utilitzar-lo des del canvi de propietari. El codi redirigia una part dels visitants a llocs fraudulents.

3. Algú accedeix al compte del gestor d’etiquetes

Qui pot publicar al teu contenidor pot executar codi al teu web sense tocar el servidor i sense deixar rastre al repositori. N’hi ha prou amb el compte d’un antic col·laborador d’agència que no es va donar mai de baixa, una contrasenya reutilitzada sense segon factor o un permís de publicació concedit «per sortir del pas».

4. Etiquetes oblidades

La campanya va acabar fa dos anys i l’agència ja no treballa amb vosaltres, però el píxel es continua carregant. Cada etiqueta òrfena és codi que ningú no vigila, d’un proveïdor de qui potser ningú no fa seguiment, i que continua rebent dades dels teus visitants.

Què s’hi juga un lloc web B2B

És fàcil pensar que això és un problema de botigues en línia. Un lloc web B2B també hi té molt a perdre:

• Formularis de contacte i de demostració que recullen el nom, el càrrec, el correu corporatiu i el telèfon de persones amb poder de decisió.
• Àrees de client i portals amb accés a comandes, pressupostos o documentació.
• Botigues B2B i pàgines de pagament o de sol·licitud de crèdit.
• Visitants que són empleats d’empreses concretes. Una redirecció a una pàgina falsa es converteix en una pesca de credencials dirigida sota la marca de la teva empresa.

L’incident de British Airways el 2018 no va començar en un gestor d’etiquetes, sinó amb un accés a la xarxa de l’aerolínia. Però mostra el cost d’un script alterat en un web: el codi maliciós capturava les dades de pagament mentre els clients completaven la compra, va afectar unes 400.000 persones i el regulador britànic va acabar imposant una multa de 20 milions de lliures.

A més, hi ha un component regulador. Quan un script de tercers es carrega a la teva pàgina, el navegador contacta directament amb aquell tercer, que rep l’adreça IP del visitant i, segons el cas, la pàgina d’origen i les galetes que ja tingués. Aquesta transferència de dades és responsabilitat teva, també d’acord amb l’RGPD. I si el teu web cobra en línia, l’estàndard PCI DSS 4.0 exigeix des de 2025, als requisits 6.4.3 i 11.6.1, que tots els scripts de la pàgina de pagament estiguin autoritzats, justificats i inventariats, i que es detectin els canvis no autoritzats.

Controls que funcionen sense frenar l’equip de màrqueting

La solució no és prohibir els gestors d’etiquetes, sinó tractar-los com una via de desplegament de codi en producció. La seva supervisió ha de formar part del manteniment web.

Fes un inventari i assigna un responsable a cada etiqueta

Llista tots els dominis externs que carrega cada tipus de pàgina: inici, blog, formularis i àrea de client. Per a cada etiqueta, anota qui la va demanar, per a què serveix, quines dades rep i fins quan es necessita. Revisa la llista cada trimestre i elimina el que no tingui responsable. És la mesura més barata i la que més redueix la superfície d’atac.

Protegeix el mateix gestor d’etiquetes

• Activa la verificació en dos passos a tots els comptes amb accés.
• Aplica el principi de mínim privilegi. Google Tag Manager separa els permisos de lectura, edició, aprovació i publicació; aprofita aquesta separació.
• Dona de baixa immediatament els usuaris d’agències i col·laboradors que ja no treballen amb tu.
• Exigeix la revisió d’una segona persona per a les etiquetes d’HTML personalitzat.
• Consulta l’historial de versions després de qualsevol canvi inesperat.

Retira les etiquetes de les pàgines sensibles

Les pàgines d’accés, de pagament o amb formularis llargs no necessiten el píxel de remàrqueting ni el mapa de calor. Limita-hi les etiquetes a les imprescindibles. Per mesurar conversions, sovint n’hi ha prou amb un esdeveniment a la pàgina de confirmació posterior, que no recull dades sensibles.

Defineix una política de seguretat del contingut (CSP)

Una CSP és una capçalera HTTP que indica al navegador des de quins dominis pot carregar scripts. Un exemple bàsic:

Content-Security-Policy-Report-Only: script-src 'self' https://www.googletagmanager.com

Comença en mode «només informe» (Report-Only): el navegador no bloqueja res, però t’avisa de cada script que no és a la llista. Aquest primer informe acostuma a revelar dominis que ningú no sabia que hi eren. Amb un gestor d’etiquetes, ajustar una CSP estricta requereix proves, de manera que convé observar abans de bloquejar.

Tingues present una limitació: la CSP no pot distingir entre una etiqueta legítima i una de maliciosa publicades des d’un contenidor que ja està autoritzat. No substitueix el control d’accés al gestor d’etiquetes; el complementa. A més, una CSP mal configurada es pot eludir: convé conèixer les tècniques d’elusió de CSP per saber quins errors cal evitar en definir-la.

Utilitza integritat de subrecursos i còpies pròpies per a biblioteques estables

Per a fitxers que no canvien, com ara una versió concreta d’una biblioteca JavaScript, l’atribut integrity permet que el navegador comprovi que el fitxer descarregat coincideix amb el que esperaves:

<script src="https://cdn.example.com/lib.min.js" integrity="sha384-HASH_DEL_ARCHIVO" crossorigin="anonymous"></script>

Si el fitxer canvia, el navegador el rebutja. Això no serveix per a scripts que canvien per disseny, com els d’analítica o el mateix contenidor del gestor d’etiquetes, però és molt útil per a biblioteques de suport. Encara millor: allotja’n una còpia pròpia. En el cas de Polyfill.io, els webs que ho feien van quedar fora de l’atac.

Vigila els canvis

Una revisió anual no és suficient. Configura alertes per quan aparegui un domini nou a les teves pàgines crítiques, revisa els informes de la CSP i comprova periòdicament quins scripts es carreguen realment en producció.

Com plantejar-ho amb l’equip de màrqueting

Aquestes mesures funcionen si l’equip de màrqueting les veu com un suport i no com un obstacle. Un acord senzill acostuma a ser suficient: qualsevol etiqueta nova es publica en menys de 48 hores, a canvi de respondre cinc preguntes.

• Quin proveïdor és i des de quin domini es carrega?
• Quines dades rep?
• Disposa del consentiment de l’usuari quan correspon?
• En quines pàgines es carregarà?
• Quan es revisa o es retira?

Conclusió: idees clau

Els gestors d’etiquetes i els scripts de tercers no són el problema. El problema és que s’instal·len com una eina de màrqueting i es comporten com a codi en producció, sense les revisions que rep el codi propi.

• Qualsevol script de tercers s’executa amb els mateixos privilegis que el teu propi codi.
• Un gestor d’etiquetes treu aquesta llista del teu repositori: l’accés al seu compte és tan crític com l’accés al servidor.
• Els atacs reals, com Polyfill.io o Magecart, aprofiten la confiança en proveïdors i dominis, no pas errors del teu web.
• Inventari, mínim privilegi i menys etiquetes a les pàgines sensibles són les mesures amb millor relació entre esforç i resultat.
• Una CSP en mode informe i la integritat de subrecursos afegeixen una capa tècnica sense bloquejar l’equip.
• Un procés senzill d’alta d’etiquetes dona agilitat a màrqueting i visibilitat a seguretat.

La pròxima vegada que algú demani afegir «només un píxel més», no cal dir que no. N’hi ha prou de saber qui el posa, quines dades veu i quan es retira.