TL;DR, Respuesta rápida
10 min de lecturaEl CNAME cloaking apunta un subdominio de tu sitio, como metrics.example.com, a un rastreador de terceros mediante un registro DNS CNAME, así que el navegador trata al rastreador como first-party y le deja poner y leer cookies en tu dominio. Safari 14 e iOS 14 limitan a 7 días las cookies puestas en respuestas de terceros con CNAME encubierto, Brave compara el nombre canónico con sus listas de filtros desde la versión 1.17, y uBlock Origin destapa los CNAME en Firefox. Un proxy inverso en tu propio servidor es una configuración distinta que no encaja en la definición de cloaking de WebKit.
¿Qué es el CNAME cloaking?
Un proveedor de tracking usa el CNAME cloaking cuando el dueño de un sitio apunta uno de los subdominios del propio sitio, como metrics.example.com, al servidor del proveedor mediante un registro DNS CNAME, de modo que el navegador trata las peticiones del proveedor como first-party. Los navegadores deciden si algo es first-party o third-party según el dominio registrable, y un CNAME esconde el destino real una capa por debajo de la web, en el DNS. El proveedor obtiene el acceso a cookies de tu propio sitio sin aparecer como un dominio separado.
John Wilander, de WebKit, explicó el efecto en una publicación del 12 de noviembre de 2020: el dominio de terceros "is cloaked as sub.blog.example and thus has the same powers as the true first party." La guía del informe de privacidad de Safari señala los endpoints con CNAME encubierto como algo que conviene auditar.
¿Cómo hace un registro CNAME que un rastreador parezca first-party?
Un registro CNAME hace que un rastreador parezca first-party porque convierte un nombre bajo tu dominio en un alias del hostname del rastreador antes de que el navegador vea una dirección IP, así que cada comprobación que hace el navegador solo ve tu dominio. La cadena es esta:
- La página en
www.example.comcarga un script o envía una petición ametrics.example.com. - El DNS responde que
metrics.example.comes un CNAME decollect.tracker.example. - El DNS resuelve
collect.tracker.examplea la dirección IP del proveedor. - El navegador se conecta, pero la URL, el nombre del certificado TLS y el ámbito de las cookies dicen
metrics.example.com.
Dos reglas de cookies hacen que a un rastreador le compense el esfuerzo. Las peticiones a metrics.example.com llevan todas las cookies con ámbito en example.com, lo que según WebKit incluye "login cookies and user identity cookies." Y la respuesta puede poner cookies nuevas para example.com mediante un encabezado Set-Cookie, que el navegador archiva como cookies first-party.
Esa segunda regla es la razón por la que los rastreadores impulsaron esta configuración. La Intelligent Tracking Prevention de Safari borra las cookies creadas en JavaScript tras 7 días sin interacción del usuario con el sitio, algo que la guía del límite de 7 días de cookies de Safari cubre en detalle. Antes de noviembre de 2020, las cookies que ponía un servidor en una respuesta HTTP quedaban fuera de ese límite. WebKit lo dijo sin rodeos: "Cross-site trackers have convinced site owners to set up CNAME cloaking in order to circumvent tracking prevention."
¿Cómo detecta Safari el CNAME cloaking?
Safari detecta el CNAME cloaking comparando el CNAME por el que se resuelve un subrecurso first-party con el dominio del propio sitio y con el CNAME del frame superior, y limita a 7 días cualquier cookie puesta en una respuesta que no coincida. WebKit lanzó la defensa en Safari 14 para macOS Big Sur, iOS 14 y iPadOS 14, anunciada el 12 de noviembre de 2020: "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days."
WebKit define el disparador con exactitud: "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists." Esa última cláusula cubre los sitios detrás de una CDN o un edge host, donde todo el sitio se resuelve a través de un CNAME. La propia tabla de WebKit recoge esos casos:
| Sitio principal (www.blog.example) | Subdominio de tracking (track.blog.example) | Caducidad de la cookie |
|---|---|---|
| Sin cloaking | Sin cloaking | Sin límite |
| Sin cloaking | Apunta a other.blog.example | Sin límite |
| Sin cloaking | Apunta a tracker.example | Límite de 7 días |
| Apunta a abc123.edge.example | Sin cloaking | Sin límite |
| Apunta a abc123.edge.example | Apunta al mismo abc123.edge.example | Sin límite |
| Apunta a abc123.edge.example | Apunta a other.blog.example | Sin límite |
| Apunta a abc123.edge.example | Apunta a tracker.example | Límite de 7 días |
La página actual de tracking prevention de WebKit extiende la misma regla a los trucos de direcciones que se saltan por completo los nombres DNS: "ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days." Eso cubre la variante en la que el registro de dirección de un subdominio apunta a la dirección IP de un proveedor en lugar de a un hostname del proveedor.
Una cookie de una respuesta encubierta caduca ahora 7 días después de ponerse, el mismo límite que tienen las cookies de JavaScript, así que en Safari el cloaking ya no consigue un ID más duradero.
¿Cómo destapan Brave y uBlock Origin los rastreadores con CNAME?
Brave y uBlock Origin destapan los rastreadores con CNAME resolviendo ellos mismos el hostname y comparando el nombre canónico con sus listas de filtros de rastreadores, y bloquean la petición si el destino real está en la lista.
uBlock Origin en Firefox. uBlock Origin 1.25.0 añadió una solicitud del permiso dns de Firefox, y sus notas de versión dicen "From now on uBO will CNAME-uncloak network requests." La función depende de la API browser.dns de Mozilla, y el equipo de investigación de Brave señaló que "this solution only works in Firefox, as Chromium does not provide the browser.dns API." La wiki de uBlock Origin dice que el ajuste "Uncloak canonical names" es un ajuste normal desde uBO 1.34.0, que está "default enabled" y que "is currently supported only on Firefox." uBlock Origin en Chrome no puede ver el CNAME en absoluto.
Brave Shields. Brave anunció el bloqueo basado en CNAME el 20 de julio de 2020 y lo llevó a todos los usuarios con Brave 1.17. Brave comprueba dos URLs en cada petición a un host con CNAME: "first, the original URL requested by the page, and second, the same URL, but with the CNAME'ed domain name replaced with the resolved 'canonical' domain name." Su ejemplo era 16ao.mathon.fr, un subdominio con aspecto first-party cuyo nombre canónico era et5.eulerian.net, un rastreador de terceros.
Hay un detalle de Brave que confunde a los dueños de sitios. Desde la versión 1.30, el modo "standard" por defecto de Shields no aplica las listas de filtros de red a los subrecursos del mismo sitio, y el modo "aggressive" las aplica a "all sub-resource requests, first and third-party alike." Las publicaciones de Brave no dicen cómo trata el modo standard un subdominio encubierto una vez destapado, así que prueba tu propio sitio en modo aggressive antes de contar con cualquiera de los dos resultados. Los bloqueadores de anuncios y los navegadores de privacidad ya recortan los totales de analítica, como explica la guía sobre el efecto de los bloqueadores de anuncios en la precisión de la analítica. El CNAME cloaking no recupera esos datos de forma fiable.
¿Qué riesgos de seguridad tiene el CNAME cloaking?
El CNAME cloaking mete el servidor de un proveedor dentro del ámbito de tus cookies, así que cada cookie que tu sitio asigna al dominio raíz, incluidas las de inicio de sesión y de sesión, llega a ese proveedor en cada petición. Es un riesgo de privacidad para los visitantes y un riesgo de seguridad para ti. La publicación de WebKit cita dos problemas. Los dueños de sitios que dejan un subdominio encubierto en su sitio después de terminar el contrato "risk full website takeovers or customer cookie hijacking if the CNAME records aren't properly managed." También cita un informe sobre 250 sitios web "of banks, healthcare companies, restaurant chains, and civil rights groups" comprometidos por un CNAME cloaking mal gestionado. Un visitante que inspecciona las peticiones en DevTools además solo ve metrics.example.com, sin ninguna señal de que los datos van a una empresa externa.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
¿Un proxy inverso es lo mismo que el CNAME cloaking?
Un proxy inverso no es CNAME cloaking, porque es tu propio servidor el que recibe la petición en tu dominio y la reenvía al proveedor, así que el DNS de ese hostname se resuelve a tu infraestructura y no a la del proveedor. Según la definición de WebKit, el cloaking significa que el subrecurso "resolves through a CNAME that differs from the first-party domain." Una ruta como example.com/api/track que gestiona tu propio servidor web no encaja.
Las diferencias que importan para la analítica:
| Pregunta | CNAME cloaking | Proxy inverso en tu servidor |
|---|---|---|
| ¿A dónde apunta el DNS? | Al hostname del proveedor | A tu propio servidor |
| ¿Quién recibe las cookies de tu dominio raíz? | El proveedor, directamente | Tu servidor, que decide qué reenviar |
| ¿Limita Safari las cookies de la respuesta? | Sí, a 7 días | No según las reglas de cloaking por CNAME o por IP |
| ¿Ven Brave o uBO un dominio de rastreador? | Sí, tras destaparlo | No hay hostname de rastreador que destapar, aunque las reglas de filtro por ruta siguen aplicándose |
| ¿Tienes que seguir declarando al proveedor? | Sí | Sí |
Un proxy no cambia quién trata los datos, así que un proveedor que construye perfiles entre sitios es el mismo problema de privacidad con cualquiera de las dos configuraciones. La guía de server side tracking cubre los servidores de etiquetado que están detrás de un CNAME.
¿Cómo compruebas si tu sitio usa CNAME cloaking?
Compruebas si hay CNAME cloaking listando cada subdominio al que tus páginas envían peticiones, resolviendo cada uno y marcando los que se resuelven a una empresa que no gestionas tú:
- Abre tu sitio en Chrome DevTools, ve al panel Network, recarga y apunta cada petición a un subdominio de tu propio dominio que no sea tu host principal.
- Para cada uno, ejecuta
dig CNAME metrics.example.comonslookup -type=CNAME metrics.example.comen una terminal. - Compara la respuesta con tu propia infraestructura. Tu CDN o tu proveedor de hosting es lo esperable. Un proveedor de analítica, de ad-tech o de datos de clientes es un rastreador encubierto.
- Revisa los encabezados de respuesta de esas peticiones en busca de
Set-Cookie. Una cookie con ámbito en tu dominio raíz que llega desde un host de un proveedor es el patrón que Safari limita. - Borra los CNAME que apuntan a proveedores que ya no usas.
¿Cómo gestiona Flowsery las configuraciones con proxy?
La documentación de Flowsery describe una configuración con proxy, no un CNAME: pasas el script en /js/main.js y el endpoint en /api/track por un proxy en tu propio servidor, y "Flowsery Analytics auto-detects proxied setups. No data-api is needed if you proxy both /js/main.js and /api/track." La documentación publica guías de proxy para Next.js, Express.js, PHP, Flask, FastAPI, Vue.js, Nginx, Caddy, Astro, Laravel y DigitalOcean. El script de tracking de Flowsery funciona sin cookies con un hash de visitante que rota cada día y no recoge datos personales, así que en ese modo no hay ninguna cookie de visitante que Safari pueda limitar. La página de la función de analítica centrada en la privacidad lista lo que guarda el rastreador y lo que deja fuera.
Preguntas frecuentes
¿Importa el CNAME cloaking para la analítica sin cookies?
La defensa de Safari contra el CNAME cloaking limita cookies, así que un script que no pone ninguna cookie no le da a Safari nada que limitar. uBlock Origin en Firefox sigue resolviendo el hostname y bloquea un subdominio encubierto cuyo nombre canónico está en sus listas, y Brave hace la misma comprobación del nombre canónico. Un script sin cookies servido a través de un proxy en tu propio servidor no les da ningún hostname de proveedor que destapar.
¿El CNAME cloaking se salta los bloqueadores de anuncios?
El CNAME cloaking se salta los bloqueadores basados en listas que solo ven el hostname, entre ellos uBlock Origin en Chrome. uBlock Origin en Firefox resuelve el nombre canónico y bloquea la petición cuando coincide con un rastreador conocido, y Brave hace la misma comprobación desde la versión 1.17. Safari no bloquea la petición, pero limita a 7 días las cookies que pone.
¿Qué versión de Safari añadió la defensa contra el CNAME cloaking?
La añadió Safari 14 en macOS Big Sur, iOS 14 y iPadOS 14, y WebKit la anunció el 12 de noviembre de 2020. El mismo límite de 7 días cubre ahora también el cloaking por dirección IP de terceros.
¿Cuenta como cloaking en Safari el CNAME de una CDN?
No, si la CDN sirve todo tu sitio. La regla de WebKit exime a un subdominio cuyo CNAME coincide con el CNAME del host del frame superior, así que un sitio y sus subdominios en el mismo edge host conservan la caducidad normal de sus cookies. El límite se aplica cuando un subdominio se resuelve a un host distinto y de terceros.
¿El server-side tagging detrás de un CNAME está a salvo de ITP?
No. Un servidor de etiquetado al que se llega mediante un CNAME hacia el servicio alojado de un proveedor encaja en la definición de WebKit de CNAME cloaking de terceros, así que Safari limita a 7 días sus cookies. Ejecutar el servidor en tu propia infraestructura, con el DNS apuntando a tu propia IP, evita esa regla.
¿Cómo quito el CNAME cloaking de mi sitio?
Borra el registro CNAME del subdominio del proveedor en tu zona DNS y quita las etiquetas que lo llaman. Si sigues necesitando al proveedor, pasa su endpoint por un proxy inverso que gestiones tú y menciona al proveedor en tu aviso de privacidad.
¿Por qué los rastreadores usan CNAME cloaking?
El navegador trata un subdominio de tu sitio como first-party. Las peticiones a él llevan las cookies del dominio raíz, y la respuesta puede crear cookies nuevas para ese dominio. Antes de noviembre de 2020, las cookies que un servidor creaba en una respuesta HTTP quedaban fuera del límite de 7 días de Safari.
¿Brave bloquea el CNAME cloaking por defecto?
Brave compara el nombre canónico con sus listas de filtros desde la versión 1.17. Desde la versión 1.30, el modo estándar de Shields no aplica listas de filtros de red a los subrecursos del mismo sitio, mientras que el modo agresivo las aplica a todas las peticiones de subrecursos. Las publicaciones de Brave no dicen cómo trata el modo estándar un subdominio camuflado, así que prueba tu sitio en modo agresivo.
¿uBlock Origin bloquea el CNAME cloaking en Chrome?
En Chrome no. Chromium no ofrece la API browser.dns, así que uBlock Origin en Chrome no puede ver el CNAME. En Firefox, el ajuste "Uncloak canonical names" viene activado por defecto y bloquea las peticiones cuyo nombre canónico coincide con un rastreador conocido.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
¿Qué es el IP address cloaking?
El IP address cloaking es la variante en la que el registro de dirección de un subdominio apunta a la IP de un proveedor en lugar de a su nombre de host. El DNS no muestra ningún CNAME. Según WebKit, ITP lo detecta y limita a 7 días las cookies de la respuesta HTTP, igual que con el CNAME cloaking.
¿Te resultó útil este artículo?
¡Cuéntanos qué opinas!
Vernos más en Google
Un clic marca Flowsery como fuente preferida y nuestros artículos aparecen más arriba en tus Noticias destacadas, el modo IA y los resúmenes con IA.
Antes de irte...
Flowsery
Analítica orientada a ingresos para tu sitio web
Rastrea cada visitante, fuente y conversión en tiempo real. Simple, potente y sin cookies.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Términos relacionados del glosario
Cómo la sincronización de cookies empareja IDs publicitarios entre sitios
El ad-tech usa la sincronización de cookies para intercambiar IDs con redirecciones y píxeles. Mira qué hacen Safari, Firefox y Chrome al respecto.
Cómo crear métricas calculadas de GA4 con una cuota de cinco huecos
Google limita las métricas calculadas de GA4 a 5 por propiedad estándar. Aprende la sintaxis, las unidades, dónde aparecen y qué no admite una fórmula.
Cómo configurar la agrupación de contenido de GA4 con un solo parámetro
Configura la agrupación de contenido de GA4 con el parámetro content_group en gtag o Tag Manager, lee la dimensión Content group y evita filas (not set).
Qué envían los user agent client hints y qué sigue viendo la analítica
Con los user agent client hints, Chrome reparte los datos del navegador en encabezados Sec-CH-UA. Mira baja y alta entropía, Accept-CH y qué lee la analítica.
Por qué el significado de visitantes únicos cambia según la herramienta
El significado de visitantes únicos depende de la herramienta: GA4 lo estima, Matomo no lo calcula en rangos largos y Adobe deduplica en todo el informe.
Google enumera siete causas distintas de not set en GA4
Google da a not set en GA4 una causa distinta por dimensión, desde un session_start ausente hasta un content_group vacío. Aquí cada causa y su arreglo.
Artículos relacionados
Cómo las cookies particionadas CHIPS dan a cada sitio su propio tarro
Poner cookies particionadas CHIPS exige Secure, SameSite=None y un atributo más, y el navegador guarda una copia separada por sitio de nivel superior.
Bajo el GDPR, la reversibilidad decide seudonimización vs anonimización
La reversibilidad decide seudonimización vs anonimización. Los datos del Article 4(5) siguen siendo personales; los datos anónimos salen del GDPR.
Qué arregla el server-side tracking y qué deja sin tocar
Qué traslada el server-side tracking a tu servidor, qué límites de cookies de Safari evita, cómo deduplicar eventos y por qué el consentimiento se mantiene.