Privacidad por defecto en la capa HTTP: cabeceras que reducen tu superficie de rastreo

La mayor parte del trabajo de privacidad ocurre en JavaScript — lógica de consentimiento, control de etiquetas, rotación de identificadores. Pero el navegador te entrega dos cabeceras de respuesta HTTP que cierran la superficie de vigilancia antes de que se ejecute un solo script, y la mayoría de los sitios no envían ninguna de las dos. Permissions-Policy y Referrer-Policy son privacy-by-design en su forma más literal: configuración, no código.

Importan más ahora que hace un año. Con la retirada en octubre de 2025 de la mayoría de las APIs del Privacy Sandbox por parte de Google, las directivas residuales de ad-tech que esas APIs introdujeron siguen cableadas en Chrome — y un sitio ahora puede desactivarlas de forma afirmativa en lugar de esperar a que las eliminen.

Permissions-Policy: deniega las funciones que nunca usas

Permissions-Policy controla qué funciones del navegador puede usar un documento y sus marcos incrustados. Es el mismo mecanismo que regula camera, geolocation y microphone — pero también regula las APIs cercanas al rastreo a las que recurre la ad-tech.

La allowlist por defecto para la mayoría de ellas es permisiva. browsing-topics, la directiva que controla la Topics API, tiene por defecto * — cualquier origen en la página, incluidos los marcos de terceros, puede llamarla a menos que indiques lo contrario. Deshabilitarla es una línea:

Permissions-Policy: browsing-topics=()

Una allowlist vacía () deniega la función a todos, incluido tu propio origen. Puedes bloquear todo el conjunto de APIs de interés publicitario y de medición en una sola cabecera:

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()

Cualquier script — propio o incrustado — que llame a document.browsingTopics() o envíe una cabecera de solicitud Sec-Browsing-Topics falla ahora con un NotAllowedError. No estás confiando en que los terceros se comporten bien; estás eliminando la capacidad a nivel de plataforma.

Estas directivas están obsoletas junto con el Privacy Sandbox, por lo que algunas desaparecerán de Chrome en las próximas versiones. Definirlas como () es inofensivo una vez que se hayan ido y protector hasta entonces.

Referrer-Policy: deja de filtrar tus URLs

Cada solicitud de navegación y de subrecurso puede llevar una cabecera Referer que nombra la página de la que vino el usuario. Las URLs completas filtran query strings, identificadores codificados en la ruta, términos de búsqueda y la estructura interna de las páginas a todos los terceros que cargas — proveedores de analítica, fuentes, CDNs, píxeles de anuncios.

Los navegadores modernos tienen por defecto strict-origin-when-cross-origin, que ya es un mínimo razonable:

Referrer-Policy: strict-origin-when-cross-origin

Bajo esta política el navegador envía la URL completa solo en solicitudes same-origin, envía solo el origen en solicitudes cross-origin seguras y no envía nada al degradar de HTTPS a HTTP. Así, https://app.example/orders/4815?token=abc llega a un tercero como https://app.example/ — origen, sin ruta, sin query.

Ese valor por defecto se convirtió en el predeterminado de la especificación en noviembre de 2020, pero aun así deberías establecer la cabecera de forma explícita. Un upstream mal configurado, un valor por defecto antiguo de un framework o una etiqueta <meta> de referrer pueden anularla, y una cabecera explícita es auditable. Si no incrustas nada sensible en las URLs y quieres ser estricto, strict-origin también elimina la ruta en las solicitudes same-origin.

Por qué esto encaja con la analítica sin cookies

Estas cabeceras y un tracker centrado en la privacidad resuelven el mismo problema desde dos direcciones. El tracker controla lo que recopila tu analítica; las cabeceras controlan lo que todos los demás en la página pueden alcanzar.

Un tracker sin cookies que deriva la identidad de un hash diario unidireccional — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — nunca necesita la URL completa del referrer ni la Topics API para hacer su trabajo. Lee document.referrer solo para atribuir el origen de una visita, y con el origen basta para eso. Así que endurecer Referrer-Policy no le cuesta nada a tu analítica mientras cierra una fuga para todas las demás solicitudes de la página.

La misma alineación se da con el rendimiento. Las cabeceras cuestan cero bytes de JavaScript y cero tiempo de hilo principal; el navegador las evalúa antes del parseo. Obtienes una mejora medible de privacidad sin impacto en el Largest Contentful Paint ni en el Interaction to Next Paint — el trade-off opuesto al de una plataforma de gestión de consentimiento, que añade peso de script para gestionar permisos que una cabecera podría haber denegado de plano.

Envíalas en el edge

Establece ambas cabeceras en tu edge o servidor de origen para que cada respuesta las lleve, incluidos los recursos estáticos y el HTML:

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin

En Cloudflare, añádelas en una Transform Rule o en un Worker; en Next.js, en la configuración headers(); en cualquier proxy inverso, una sola línea add_header. No hay riesgo de despliegue: estás denegando capacidades que no usas y recortando datos que nunca quisiste enviar.

La privacidad por diseño suele plantearse como una decisión de arquitectura. En la capa HTTP son dos líneas de configuración, y vienen abiertas por defecto hasta que las cierras.

Fuentes

• Cabecera Permissions-Policy (MDN Web Docs)
• Permissions-Policy: directiva browsing-topics (MDN Web Docs)
• Cabecera Referrer-Policy (MDN Web Docs)
• Controla las funciones del navegador con Permissions Policy (Chrome for Developers)
• Actualización sobre los planes para las tecnologías del Privacy Sandbox (Google)