La URL de la barra no es, por sí sola, un enlace para reenviar
Marketing pega una landing en el grupo. Soporte copia la URL de una queja al ticket. Ingeniería deja un paso de reproducción en el hilo. En los tres casos el atajo es el mismo: seleccionar la barra, copiar, pegar. Esa barra muestra la URL completa del documento actual. Según el modelo WHATWG, como mínimo tiene esquema, anfitrión, ruta, consulta (después de ?) y fragmento (después de #). El fragmento, por defecto, no entra en HTTP: eso ya lo cubrió la nota anterior. La consulta viaja en la línea de petición y también viaja en el portapapeles.
La consulta casi nunca hace falta para abrir la página. Puede que hayas llegado desde un correo con seguimiento, un clic de pago o una tarjeta social que añadió su propio token. La página solo necesita /producto/42. La barra enseña /producto/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…. Para analytics es una visita atribuible. Para quien lea la cadena a continuación, es un perfil que no debería estar en un ticket: de qué campaña viniste, si acabas de pulsar un anuncio, si el proveedor de correo numeró a este destinatario.
HTTPS solo protege el salto frente a quien escucha en el camino. No borra la barra, el historial del navegador, el almacenamiento del chat, las capturas ni los registros de acceso. La nota de OWASP sobre exposición de información en cadenas de consulta es directa: incluso en un canal cifrado, la consulta sigue apareciendo en Referer, registros web, sistemas compartidos, historial del navegador, cachés y en quien mira por encima del hombro. Antes de enviar, la pregunta no es «¿este sitio es seguro?». Es «¿este interrogante lleva etiquetas que no deberían salir de esta pestaña?».
UTM nombra una campaña. Un ID de clic nombra este clic.
Ambos tipos suelen convivir en una sola URL. Hacen trabajos distintos y filtran cosas distintas. El primero es una etiqueta de campaña que tú (o la plataforma de anuncios) escribiste a propósito. El centro de ayuda de Google Analytics los llama campaign parameters y da el ejemplo estándar: https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale. La documentación dice que, si añades parámetros, debes usar juntos utm_source, utm_medium y utm_campaign. Las extensiones incluyen utm_id, utm_term, utm_content y utm_source_platform. Los valores distinguen mayúsculas: utm_source=google y utm_source=Google se parten en dos filas del informe.
Estas etiquetas, por lo general, no cifran a una persona. Describen un canal y una campaña: qué boletín, qué rebajas de verano, el enlace de arriba o el de abajo. Reenviarlas a un chat externo igualmente filtra la estructura interna de medios. El destinatario lee qué campaña empujas y si el clic fue correo o de pago, y puede imaginar tu ruta de captación. Para un competidor o un tercero sin relación, eso es más de lo que exige «abre esta página».
El segundo tipo es un token de clic que el anuncio o el correo añade por su cuenta. Nombres habituales: gclid de Google Ads, dclid de Display & Video 360, gbraid / wbraid en escenarios iOS, fbclid de Meta, msclkid de Microsoft Ads, twclid de X y tokens de correo como mc_eid. Su trabajo es atar «este clic» al registro de la plataforma, no darte una frase legible. El valor es opaco para el destinatario y legible para la plataforma. Reenviar una cadena que aún tiene fbclid o gclid entrega una credencial de clic enlazable. Tokens como mc_eid se acercan a «este mensaje fue a esta fila de suscriptor».
Hay una tercera capa: los parámetros de atribución o de compartir del propio sitio. Marketplaces y sitios de contenido suelen añadir spm, scm, pvid, share_token o refer_share_id. No son la especificación UTM de Google, pero convierten una «página de producto limpia» en un rastro de quién la compartió y desde dónde. Una política que solo borre utm_* deja esta capa intacta.
| Tipo | Claves típicas | Problema al reenviar la URL |
|---|---|---|
| Etiquetas de campaña | utm_source, utm_medium, utm_campaign |
Filtran canal y nombre de campaña; la página no los necesita para abrirse |
| IDs de clic / destinatario | gclid, fbclid, mc_eid, msclkid |
Pueden unirse de vuelta a un clic o a un registro de suscriptor |
| Atribución del sitio | spm, pvid, share_token |
Llevan una ruta de compartir o un rastro de referencia |
| Parámetros de negocio | id, q, sku, page |
Suelen dejarse; si los quitas, la página da 404 o el resultado cambia |
Dónde acaba la cadena de consulta cuando pegas
CWE-598 —hoy titulada Use of HTTP Request With Sensitive Query String— formula el defecto así: se colocaron datos sensibles en la consulta. Luego aparecen en el historial del navegador, viajan a otros sitios por Referer, se escriben en registros web o se copian a otros archivos. La entrada cambió de nombre en la versión 4.20 de abril de 2026 para subrayar que GET no es el único método que puede llevar consulta: también POST, PUT y DELETE. La mitigación es concreta: pon los datos sensibles en el cuerpo o en cabeceras, no en la cadena de consulta.
La mayoría de los parámetros de marketing no son contraseñas ni tokens de sesión. La superficie de exposición es la misma. Pega una URL completa en un mensajero y creas al menos estas copias: el almacén de mensajes del proveedor, el historial local del destinatario y —si reenvía— el almacén del siguiente salto. Si la abre, el registro de acceso del destino anota una línea de petición que aún tiene los parámetros. Si esa página carga un script o una imagen de terceros, la URL completa también puede ir en Referer hacia un anfitrión de anuncios o analytics. Los «sistemas compartidos» de OWASP son lo de siempre en una empresa: tickets, documentos, monitores de error, reproducción de sesión. Un enlace pensado solo para reproducir un fallo se vuelve buscable en claro en esos sistemas.
Por eso «el sitio usa HTTPS» no responde a la pregunta del reenvío. HTTPS dificulta que un observador en el camino lea el texto en claro. No impide que tú pegues ese texto en el siguiente sistema. Los fallos reales de CWE-598 incluyen una cámara que puso una contraseña en la consulta y un producto de comunicaciones que puso un token de acceso en GET. Son el mismo tipo de error, solo que más grave. UTM e IDs de clic suelen ser más leves. El mecanismo es idéntico: lo que queda después del interrogante es lo que la gente copia y lo que los sistemas registran.
No hagas la demostración con una URL real de inicio de sesión, restablecimiento de contraseña o token de un solo uso. Cuando necesites comparar parámetros, usa una página pública de producto o de documentación y añade valores de prueba desechables, por ejemplo utm_campaign=canary-2026.
Referer puede llevar la consulta a un tercero
Copiar y pegar es un envío activo. También hay uno pasivo: cuando el destinatario abre la página, la política por defecto del navegador dice a las peticiones siguientes «de dónde vengo». El nombre estándar de esa cabecera es Referer (le falta una r). La nota de privacidad de Referer en MDN usa un ejemplo familiar: una página de restablecer contraseña con enlaces sociales en el pie; sales y puedes entregar una dirección con token al sitio social. Una imagen de terceros en la página puede enviar la URL completa actual al anfitrión de la imagen del mismo modo.
El navegador decide cuánto enviar con Referrer-Policy. Chrome y motores parecidos usan por defecto strict-origin-when-cross-origin: las peticiones del mismo origen pueden llevar la URL completa (ruta y consulta); una petición de otro origen sin degradar el esquema solo envía el origen (esquema + anfitrión + puerto); de HTTPS a HTTP no envía nada. La guía de referrer de web.dev trata ese valor por defecto como un compromiso entre privacidad y utilidad. Bloquea algunos casos de «consulta completa a otro anfitrión». No bloquea las peticiones de analytics del mismo origen, y no ayuda si el sitio pone unsafe-url o deja la política sin definir en un cliente antiguo que aún envía la URL entera.
Para «solo se lo mandé a un compañero», Referer sigue importando: en cuanto pulsa, las etiquetas utm_* y los IDs de clic que pegaste pueden viajar un salto más. Si la landing tiene un píxel de terceros, un widget de soporte o una fuente en una CDN, y la política permite la URL completa, esos parámetros aparecen en los registros de esos anfitriones. Quitar los rastreadores de la consulta antes de enviar corta los dos saltos: el texto en claro en el historial del chat y un Referer que podría dispararse al abrir.
El contraste con el fragmento merece una frase más. Una clave detrás de # está diseñada para no entrar en la línea de petición, así que tampoco entra en las implementaciones habituales de Referer. Una consulta no tiene esa capa. Las etiquetas de campaña y los IDs de clic van detrás de ? para que servidores y scripts los lean: precisamente por eso acaban en los registros. Para comprobar «el interrogante entra en la petición, la almohadilla por lo general no», usa los pasos de Por qué el fragmento # de una URL encaja para una clave y cuándo esa protección falla.
El sistema puede quitar algunos tokens. Eso no es una política de envío.
Apple documenta un recorte integrado. En la página de funciones de privacidad, la protección contra el seguimiento de enlaces se formula así: al compartir enlaces en Mensajes se quita la información extra que algunos sitios añaden a las URL, para que no puedan rastrearte a ti ni a quien lo recibe. Safari en navegación privada se describe aparte: esa protección quita el seguimiento añadido a las URL mientras navegas. Apple publica la capacidad, no una lista de parámetros.
No hay una lista oficial completa. Las comprobaciones de la comunidad (PrivacyTests.org y similares) suelen citar gclid, fbclid, mc_eid, twclid y dclid. Las etiquetas de campaña como utm_source suelen quedarse. La cobertura también tiene bordes: Safari normal, un navegador de terceros y un WebView dentro de una app no son los mismos caminos que compartir en Mensajes o la navegación privada. Un destinatario en Android, en Chrome de escritorio o abriendo desde WhatsApp o Teams no lo quitará por ti.
Así que «mi teléfono ya quita los parámetros de seguimiento» solo significa: en un sistema concreto, en una app concreta, algunos IDs de clic pueden borrarse antes de abrir. No significa: la cadena que pegaste en el ticket ya estaba limpia. El envío ocurre al copiar, en un sitio donde el sistema operativo aún no ha entrado. Lo que controlas es el portapapeles, no si el otro dispositivo volverá a recortar.
Qué quitar y qué dejar
Una regla que puedes ejecutar: pregunta primero si la página sigue abriéndose sin esta clave. Un id de producto, una búsqueda q, un número de page, un lang o una consulta que el propio documento necesita cambiarán el recurso si las quitas. Las etiquetas de campaña, los IDs de clic, los números de destinatario de correo y los tokens de compartir suelen cambiar solo la atribución, no la página.
La segunda pregunta es para qué es el enlace. Un compañero que reproduce un fallo necesita una dirección de recurso estable, no utm_campaign=summer-sale. Un cliente que debe «abrir este producto» necesita sku, no el gclid de tu último clic. Conserva UTM solo cuando la tarea sea «entra por esta campaña etiquetada para que contemos este reenvío». Incluso entonces, no adjuntes tu propio ID de clic.
Borrar a mano se deja claves. Una URL de pago real puede llevar cinco o seis campos utm_*, un ID de clic y dos o tres tokens del sitio. Barrer de derecha a izquierda a menudo borra id y deja fbclid. Un método más estable va por nombre de clave: quita todo prefijo utm_; quita una tabla conocida de IDs de clic; si la tarea lo permite, quita también claves habituales de analytics (_ga, _gl, mc_eid, mkt_tok) y atribución frecuente de tiendas. Deja ruta, anfitrión y consulta de negocio. Después, mira la lista de «claves quitadas», no solo si el resultado «parece más corto».
Conservador y estándar son dos preferencias de riesgo, no dos grados de anonimato. Conservador: toca solo UTM e IDs de clic, deja claves personalizadas desconocidas, para no borrar un parámetro de negocio que aún no has visto. Estándar: también quita analytics habitual y atribución de tiendas, lo que encaja cuando el enlace sale de la empresa o aterriza en un espacio público. Ninguno puede afirmar «esto ya es anónimo». Una ruta aún puede contener un nombre de usuario. Una consulta email= no está en la tabla UTM. La limpieza por reglas cubre claves de seguimiento conocidas, no cualquier campo sensible. Teléfonos, DNI y claves en el cuerpo del mensaje necesitan un enmascarado aparte. No esperes que quitar parámetros de URL termine ese trabajo.
La frase más corta que vale la pena mandar a un compañero: usa ruta más parámetros de negocio para reproducir; usa UTM para contar, y nunca adjuntes tu propio ID de clic. Si no estás seguro, quita primero utm_* y *clid, y luego lee a mano las claves que queden.
Compruébalo aquí: la lista de quitados y luego Red
«Limpieza local, no se sube nada» no se demuestra solo. Lo que puedes ver en el momento son tres cosas: qué claves se quitaron, qué claves quedan y si tu URL original salió como dato de negocio.
Primero construye un canario. Abre una página pública que no implique a un cliente real y añade ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42. Pega la cadena entera en el limpiador. Al terminar, las cuatro claves de seguimiento deberían haber desaparecido y id=42 debería seguir ahí. Si la herramienta lista los nombres quitados, recorre esos nombres uno a uno. No te quedes en «la URL se acortó».
Luego abre Red (Network) en las herramientas de desarrollo, activa Preserve log y busca en el filtro canary-share o la consulta canario completa. No debería aparecer en la línea, la consulta ni el cuerpo de un XHR / Fetch, ni en la consulta o el cuerpo de analytics. Los estáticos, estilos y scripts pueden aparecer: son los archivos de la propia página. El fallo es que la cadena original salga como campo de negocio. Un título o una ruta que diga «privacidad» o «limpiar» es lo esperado. El contenido completo de la caja de entrada, no.
- Construye una URL canario con
utm_*,fbclidy unidde negocio. No uses un cliente real ni el nombre de una campaña en marcha. - Tras limpiar, mira la tabla: claves de seguimiento en el lado «quitadas»,
idaún en la URL resultado. - Busca en Red la cadena canario. Un acierto en cualquier petición de negocio significa que el original salió de esta pestaña.
La prueba es estrecha: en esta ejecución, las claves de seguimiento conocidas desaparecieron por regla, la clave de negocio se quedó y el original no salió de esta pestaña como campo HTTP observado. No demuestra que una extensión nunca leyó la entrada, ni que un rastreador personalizado fuera de la tabla se haya tratado. Si cambias de navegador o de lista de reglas, vuelve a correr el canario.
Practica las reglas en una página que se abre sin cuenta
Si quieres una herramienta que escriba en la página la lista de lo quitado, empieza por Limpiar enlaces de MakePwd. Se abre sin registro y sin cuenta. El análisis de la URL y el recorte de parámetros ocurren en esta pestaña. Según las notas del producto, la cadena original no se envía como petición ni se escribe en analytics. El modo estándar quita utm_*, IDs de clic de anuncios, parámetros habituales de analytics y atribución frecuente de tiendas (incluido Mercado Libre y tiendas chinas). El modo conservador solo quita UTM e IDs de clic. La ruta y los parámetros de negocio como id y q se quedan. Puedes enviar hasta 100 URLs de una vez. Una línea de más de 8 KB se rechaza. Solo se aceptan http o https.
Practica con el canario de arriba, no con un ID de clic de una campaña en marcha. Tras una pasada, mira dos sitios: la lista de quitados en el panel de resultado y Red, por si aparece la cadena original. La lista responde «¿borré las claves correctas?». Red responde «¿se subió?». Las dos tienen que pasar antes de decirle a un compañero: estas son las claves que quité, y busqué el canario sin acierto de salida.
La limpieza solo trata la forma del enlace. Teléfonos, DNI, correos y API keys en un chat o en el cuerpo de un ticket pertenecen a Ocultar datos, en la misma página: se enmascaran por patrón y luego los revisa una persona. MakePwd no afirma certificación RGPD ni equivalente. Si el resultado limpio sigue siendo un secreto que no debe quedarse, envíalo una vez con el enlace de un solo uso y deja la clave en el fragmento # de la URL. Para un archivo entero, usa Cifrar archivo en este dispositivo para hacer .lock / .enc y luego envíalo por disco o correo. Ninguno de esos pasos pide iniciar sesión.
Preguntas frecuentes
¿El destinatario llega a la página si quito el UTM?
Sí, si quedan los parámetros de negocio y la ruta. UTM e IDs de clic sirven a la atribución, no al enrutado. Quita utm_campaign o fbclid y la landing debería seguir abriéndose por la ruta y el id. Si obtienes un 404 o un resultado distinto, tocaste una clave de negocio. Pasa a Conservador y compara las claves una a una.
¿HTTPS ya protege estos parámetros?
No en el momento de enviar. HTTPS baja el riesgo de que alguien escuche en el camino. No borra la barra, el historial, el chat ni los registros. OWASP indica que, incluso en un canal cifrado, la consulta sigue apareciendo en Referer, registros web, sistemas compartidos e historial del navegador. Si debes pegar la URL completa es una pregunta distinta de si el sitio tiene certificado.
Apple quita rastreadores. ¿Tengo que hacerlo yo igual?
Sí. La función del sistema aplica en caminos documentados como compartir en Mensajes y navegar en Safari privado, y Apple no publica una lista completa de claves. El UTM suele quedarse. Cuando pegas en un ticket o en un chat de Android, esas protecciones no corren por ti. Una política de envío mira el portapapeles, no si el sistema del destinatario volverá a recortar.
¿Un enlace limpio también quita el id del producto?
No debería, si la herramienta va por nombres. id, q y sku no son un prefijo utm_ y no están en la tabla habitual de IDs de clic. La comprobación es un canario que lleva claves de seguimiento y una clave de negocio, y confirma que solo desaparecieron las primeras. Si un sitio escribe el seguimiento en un nombre propio, la tabla de reglas no lo conocerá. Borra esa clave a mano o amplía la lista.
Tres cosas que recordar antes del próximo envío
Primero: seleccionar toda la barra no es lo mismo que «seguro para enviar». Parte la consulta en etiquetas de campaña, IDs de clic, atribución del sitio y parámetros de negocio. Solo el último tipo debería quedarse por defecto. Segundo: HTTPS y un recorte automático del sistema no sustituyen revisar el portapapeles. La consulta acaba en historial, tickets y registros, y puede viajar otra vez en Referer. Tercero: verifica dos sitios: la lista de claves quitadas y una búsqueda en Red de tu canario.
Si la siguiente pregunta es si el texto en claro salió de esta pestaña como dato de negocio, lee Cifrar en el navegador: cómo comprobar que el original no salió de este dispositivo. Esta nota solo convierte «qué campos de la consulta no deberían viajar cuando reenvías una URL completa» en un rango que puedes escribir en una conclusión.