Auditar terceros en sitios web: 4 fugas ocultas

En pocas palabras: No. Un escaneo automático de terceros puede pasar limpio y aun así dejar conexiones vivas: acá detectó 2 de 4 (Nominatim y Macrostrat), pero no vio Paleobiology Database ni GPlates, cuyas URLs estaban ocultas en variables. Auditá también con code review y la pestaña Network.

Un sitio con una regla estricta (el navegador del lector habla con el origen y con nadie más) corrió un escaneo automático de terceros que pasó limpio. Pero había cuatro conexiones a terceros activas, y el escaneo solo vio dos. La lección directa: auditar terceros en sitios web con una herramienta automática no alcanza, porque una URL escondida en una variable intermedia es invisible para el scanner.

Cloudflare es una plataforma de infraestructura global que proporciona servicios de CDN, DNS, seguridad web y protección DDoS. Fue fundada en 2009.

Una solicitud de terceros (third-party request) es cualquier conexión que el navegador del usuario abre hacia un dominio distinto al de tu sitio: analytics, fuentes de un CDN, mapas, píxeles de redes sociales o APIs externas. Se generan desde scripts, embeds o plugins, viajan datos del visitante (IP, ubicación, comportamiento) y muchas veces el dueño del sitio ni sabe que existen.

¿Qué son las solicitudes de terceros en un sitio web?

Son las conexiones que tu página fuerza al navegador del visitante hacia dominios ajenos al tuyo. Si tu sitio vive en tudominio.com pero carga Google Analytics, una fuente de Google Fonts o un mapa de OpenStreetMap, cada una de esas es una solicitud de tercero. La diferencia con las first-party (las que van a tu propio servidor) es quién termina viendo los datos del usuario.

El problema no es que existan. Muchas son legítimas y hasta necesarias. El problema es que son invisibles. Vos publicás una nota, insertás un video, activás un plugin de compartir en redes, y sin darte cuenta el navegador de tu lector empieza a hablar con cinco servidores que vos nunca elegiste. Relacionado: gestión segura de secretos en Cloudflare.

Ponele que instalás un plugin de WordPress para mostrar reseñas. Funciona bárbaro. Lo que no ves es que ese plugin, en cada carga de página, manda la IP del visitante a un servidor de analítica del propio desarrollador. Vos no lo pediste. El usuario tampoco. Pero pasa igual, en cada visita, sin registro visible.

¿Por qué las solicitudes de terceros son un riesgo de privacidad y legal?

Porque cada tercero que recibe una request se lleva datos del visitante sin que este lo autorice: dirección IP, ubicación aproximada, IDs de sesión, y a veces lo que la persona tipeó o dónde hizo clic. En el caso documentado en el reporte de dev.to, una página mandaba el nombre del lugar que el usuario escribía a Nominatim de OpenStreetMap, y otra enviaba las coordenadas del punto clickeado a Macrostrat.

Eso, en términos legales, no es un detalle. Bajo el RGPD europeo y la LOPDGDD española, el dueño del sitio es responsable de esos datos aunque el que los procese sea el tercero. Si nunca pediste consentimiento para ese envío, estás en falta.

Y acá viene lo incómodo del caso: el sitio tenía una regla explícita de “el navegador habla con el origen y con nadie más”. La política decía una cosa. El código hacía otra. Dos páginas venían rompiendo esa promesa en público durante meses, y recién un chequeo nuevo a nivel del corpus completo levantó la alfombra.

¿Cómo un escaneo automático puede pasar por alto fugas de terceros?

Un escaneo automático falla cuando la URL del tercero no está escrita como texto literal dentro de la llamada, sino guardada en una variable. El scanner busca patrones directos (la URL pegada al fetch), no sigue el rastro de una variable declarada una línea antes. Ese es exactamente el agujero por el que se colaron dos de las cuatro fugas del caso. Esto se conecta con lo que analizamos en validación de servidores DNS autorizados.

El detalle técnico vale la pena. El chequeo no era vago: buscaba literales de URL sentados adentro de las llamadas, que es una cosa razonable de buscar. Cazaba la forma obvia, la URL de GPlates escrita directa. Pero la página real tenía la misma URL asignada a una variable intermedia en la línea inmediatamente anterior. Comportamiento idéntico, detección cero.

¿Cuál es la moraleja? Que un escaneo que “pasa limpio” te da una falsa sensación de seguridad. La fuga que la herramienta existía para encontrar estaba corriendo mientras el reporte decía “todo OK”. Por eso un escaneo automático solo es el piso, nunca el techo.

¿Con qué herramientas y métodos se detectan las solicitudes de terceros?

Con una combinación de inspección manual del navegador y escáneres automáticos. La pestaña Network de las DevTools (F12) te muestra cada conexión que abre la página en tiempo real, mientras que herramientas como Usercentrics o escáneres de cookies rastrean el sitio completo. Ninguna sola es suficiente: la manual ve lo que el scanner no sigue, y el scanner cubre páginas que vos nunca abrirías a mano.

Inspección manual (lo que ves con tus propios ojos)

• Pestaña Network de DevTools: abrís F12, recargás la página y filtrás por dominio. Todo lo que no sea tu dominio es un tercero.
• Pestaña Application: ahí ves las cookies que setea cada tercero, útil para el inventario de consentimiento.
• Code review del repositorio: el paso que salvó el caso. Buscar a mano las llamadas fetch, incluidas las que arman la URL en una variable.

Escáneres automáticos (cobertura a escala)

• Escáneres de cookies y consentimiento: recorren todas las URLs del sitio y listan cada tercero que dispara.
• Chequeos a nivel de corpus: como el del caso, revisan todo el código de una, pero solo cazan patrones literales.
• Content Security Policy (CSP) headers: más que detectar, previenen. Definís a qué dominios puede conectarse el navegador y el resto queda bloqueado.

Método	Detecta	Punto ciego	Costo
Pestaña Network (DevTools)	Toda conexión en la página que abrís	Solo las páginas que revisás a mano	Gratis
Escáner de cookies	Terceros en todo el sitio	Requests dinámicas que no dejan cookie	Gratis a pago
Chequeo automático de código	URLs literales en el código	URLs guardadas en variables	Gratis
Code review manual	Cualquier patrón, incluso variables	Lento, depende del revisor	Tiempo
CSP headers	Bloquea (no solo detecta)	Config inicial exige inventario previo	Gratis

¿Cumplís con RGPD y LOPDGDD en tus third-party requests?

Cumplís solo si pediste consentimiento previo y explícito para cada tercero antes de que dispare, con transparencia total sobre quién recibe los datos. La responsabilidad es tuya como dueño del sitio, incluso cuando las cookies o las requests son de un servicio externo. Y ojo: el rechazo de cookies no puede bloquear el uso del sitio, tiene que ser tan fácil rechazar como aceptar. Te puede servir nuestra cobertura de rendimiento de contenedores en la nube.

• Consentimiento antes del disparo: nada de terceros cargando en el primer render sin permiso.
• Política de privacidad accesible: con el listado real de terceros y qué datos maneja cada uno.
• Plazo ante brecha: si hay una fuga de datos, la comunicación a la autoridad (AEPD en España) es dentro de las 72 horas.
• Simetría en el consentimiento: rechazar tiene que costar lo mismo que aceptar, un clic.

¿Cuáles son los pasos para auditar tu sitio y eliminar fugas?

El orden que funciona arranca por el inventario y termina en la reinspección. No es glamoroso, pero es lo que separa un “pasó el escaneo” de un sitio que de verdad respeta su propia política. Si alojás el sitio y querés control total sobre qué se conecta desde tu infraestructura, un hosting propio en donweb.com te deja aplicar CSP y revisar logs sin depender de configuraciones ajenas.

• Listá todos los terceros conocidos: analytics, redes sociales, ads, mapas, plugins. Lo que sabés que está.
• Corré un escáner automático: para cubrir todas las URLs sin abrirlas una por una.
• Revisá la pestaña Network en varias páginas: no solo la home. Las fugas del caso estaban en páginas internas específicas.
• Hacé code review de las llamadas dinámicas: buscá URLs armadas en variables, el punto ciego clásico.
• Documentá cada hallazgo en una planilla: tercero, qué datos manda, si hay consentimiento.
• Bloqueá o remové lo no esencial: con CSP o quitando el script.
• Reinspeccioná después de cada cambio: un deploy nuevo puede reintroducir una fuga.

Mejores prácticas para prevenir fugas a terceros

La regla base es seguridad por defecto: solo los terceros imprescindibles, todo lo demás denegado. El caso lo muestra al revés, un sitio que quería exactamente eso y aun así se le colaron cuatro conexiones. La diferencia entre la intención y la realidad se cierra con auditoría periódica, no puntual.

• Denegar por defecto con CSP: configurá el header Content-Security-Policy para que el navegador solo pueda conectarse a los dominios que vos listaste.
• Code review de cada script nuevo: antes de que entre a producción, no después.
• Auditoría continua, no una vez al año: cada deploy es una oportunidad de reintroducir una fuga.
• Documentar cambios: si nadie anota por qué está esa llamada, dentro de seis meses nadie sabe si se puede sacar.

Qué está confirmado y qué no

Confirmado (según el reporte): el sitio tenía una política de solo-origen, un escaneo detectó dos fugas (Nominatim y Macrostrat) y una revisión posterior encontró dos más (Paleobiology Database y GPlates Web Service). La de GPlates estaba en una variable intermedia y por eso el escaneo no la vio. Las cuatro estaban activas en producción.

No confirmado / no aplica a tu caso: el reporte no dice cuántos usuarios fueron afectados ni si hubo denuncia formal. Tampoco es un sitio de hosting ni de WordPress, es un proyecto propio con páginas de astronomía y geología. Las herramientas comerciales que se nombran para auditar (escáneres de cookies, plataformas de consentimiento) son ejemplos de categoría, no una recomendación validada para tu stack. Probalas y verificá vos mismo con la pestaña Network.

Errores comunes al auditar terceros

• Confiar en que “el escaneo pasó”: el caso entero es esto. Un escaneo limpio no significa que no haya fugas, significa que el scanner no las encontró. Corregilo cruzando con code review manual.
• Auditar solo la home: las cuatro fugas estaban en páginas internas específicas (una de cielo, otra de geología). Revisá cada tipo de página, sobre todo las que llaman APIs externas.
• Ignorar las URLs dinámicas: si tu script arma la URL concatenando variables, ningún patrón literal la va a cazar. Buscá los fetch a mano en el código.
• Auditar una vez y olvidarse: un deploy posterior puede reintroducir el mismo tercero. La reinspección después de cada cambio no es opcional.

Preguntas Frecuentes

¿Cómo sé si mi sitio envía datos a terceros sin autorización?

Abrí las DevTools del navegador (F12), andá a la pestaña Network y recargá la página. Cada conexión hacia un dominio que no sea el tuyo es un tercero. Filtrá por dominio para ver la lista limpia y repetí el chequeo en varias páginas del sitio, no solo en la home. Para más detalles técnicos, mirá opciones de almacenamiento distribuido.

¿Por qué un escaneo automático no detecta todas las fugas?

Porque los escáneres buscan URLs escritas como texto literal dentro de las llamadas, y no siguen el rastro cuando la URL está guardada en una variable. En el caso documentado, la conexión a GPlates estaba en una variable de la línea anterior y el escaneo pasó limpio mientras la fuga corría en producción.

¿El RGPD me hace responsable de las cookies de terceros?

Sí. Bajo el RGPD y la LOPDGDD, el dueño del sitio es responsable de los datos que sus terceros procesan, aunque las cookies o las requests sean de un servicio externo. Necesitás consentimiento previo y explícito antes de que cada tercero dispare, y una política de privacidad que liste quién recibe qué.

¿Cómo bloqueo solicitudes no deseadas de terceros?

Con un header Content-Security-Policy (CSP) que defina a qué dominios puede conectarse el navegador; todo lo que no esté en esa lista queda bloqueado. Es la forma de “denegar por defecto”. Antes de configurarlo necesitás el inventario completo de terceros legítimos para no romper funcionalidad.

¿Cada cuánto tengo que auditar los terceros de mi sitio?

Después de cada deploy o cambio de código, no una vez al año. Un cambio nuevo puede reintroducir una conexión a un tercero que ya habías sacado. La auditoría periódica, combinada con code review de los scripts nuevos antes de que entren a producción, es lo que evita que la política y el código real se separen.

Conclusión

Lo que cambió con este caso no es una vulnerabilidad nueva, es la demostración concreta de que un escaneo automático te miente por omisión. Cuatro fugas activas, dos invisibles para la herramienta, en un sitio que se propuso explícitamente no tener terceros. Si le pasó a un proyecto con esa disciplina, en un WordPress cargado de plugins la superficie es enorme.

¿Qué hacer hoy? Abrí las DevTools, revisá la pestaña Network en tus páginas más cargadas, corré un escáner de cookies para la cobertura a escala, y después hacé code review de las llamadas dinámicas que ninguna herramienta sigue. Documentá cada tercero, pedí consentimiento donde falte y activá CSP para denegar por defecto. La auditoría es continua o no sirve.

Fuentes

• Our third-party scan passed. Four upstreams were live – reporte original del caso (dev.to)
• Usercentrics – guía de auditoría de privacidad de datos y escaneo de terceros
• Protección de Datos 360 – auditoría web y cumplimiento RGPD
• RGPD y cookies para empresas – obligaciones de consentimiento
• Ours Privacy – detección automática de scripts y sus límites