¿Qué es Referrer-Policy?

La cabecera HTTP Referrer-Policy controla cuánta información sobre la página de origen se incluye en la cabecera de petición Referer cuando un usuario navega desde tu sitio a otro, o cuando tu página carga recursos desde fuentes externas. Cada vez que alguien hace clic en un enlace, cada vez que se carga una imagen desde un CDN, cada vez que se dispara un script de analítica, el navegador puede enviar potencialmente la URL de la página actual al servidor de destino. Referrer-Policy te permite decidir cuánto de esa URL compartir.

(Una nota rápida sobre la grafía: la cabecera HTTP se escribe "Referer" con una sola "r" debido a un error ortográfico en la especificación original de HTTP de principios de los 90. La cabecera de política utiliza la grafía correcta "Referrer" con dos erres. Ambas grafías son intencionadas.)

Qué contiene la cabecera Referer y cuándo se envía

Por defecto (sin una Referrer-Policy), el navegador envía la URL completa de la página actual como cabecera Referer en la mayoría de las peticiones salientes. Esto incluye:

• Navegación: cuando un usuario hace clic en un enlace hacia otro sitio web, el destino recibe la URL completa de la página de la que viene.
• Peticiones de subrecursos: cuando tu página carga imágenes, scripts, hojas de estilo o fuentes desde dominios externos, cada petición incluye la cabecera Referer.
• Envíos de formularios: cuando un formulario envía datos a una URL externa, se incluye la cabecera Referer.
• Peticiones AJAX y Fetch: las llamadas a APIs hacia servicios externos también incluyen por defecto la cabecera Referer.

Supongamos que un visitante está en esta URL de tu sitio WordPress:

https://tusitio.com/miembros/dashboard?session=abc123&plan=premium

Si esa página contiene una imagen incrustada de un proveedor externo de analítica o de una red publicitaria, el servidor de ese proveedor recibe la URL completa en la cabecera Referer, incluidos los parámetros de consulta con el token de sesión y la información del plan. Este es el problema de privacidad que aborda Referrer-Policy.

Todos los valores de Referrer-Policy explicados

La cabecera Referrer-Policy admite ocho valores distintos. Cada uno define un nivel diferente de compartición de información:

• no-referrer: nunca envía la cabecera Referer. El destino no recibe información sobre el origen de la petición. Es la opción más privada, pero puede romper funcionalidades que dependen de los datos del referrer (algunas protecciones CSRF, por ejemplo).
• no-referrer-when-downgrade: envía la URL completa, pero elimina el Referer al navegar de HTTPS a HTTP (una "degradación"). Este fue el valor por defecto del navegador durante muchos años. Protege frente a la fuga de URLs al salir de un contexto seguro, pero comparte todo en navegaciones HTTPS a HTTPS.
• origin: envía solo el origen (esquema, host y puerto) pero no la ruta ni la cadena de consulta. Así, https://tusitio.com/miembros/dashboard?session=abc123 se convierte en simplemente https://tusitio.com/. El destino sabe desde qué sitio viene el visitante, pero no desde qué página concreta.
• origin-when-cross-origin: envía la URL completa para peticiones del mismo origen (enlaces dentro de tu propio sitio) pero solo el origen para peticiones cross-origin. Esto da a tu propia analítica y a tus herramientas internas datos completos del referrer mientras limita lo que ven los sitios externos.
• same-origin: envía la URL completa solo para peticiones del mismo origen. Para peticiones cross-origin, no envía Referer en absoluto. Es muy privada para la navegación externa pero significa que los servicios externos no reciben ningún dato de referrer.
• strict-origin: envía solo el origen (como el valor origin), pero elimina por completo el Referer en las degradaciones de HTTPS a HTTP. Combina la privacidad de origin con la protección frente a degradación de no-referrer-when-downgrade.
• strict-origin-when-cross-origin: el valor recomendado más habitualmente. Envía la URL completa para peticiones del mismo origen, solo el origen para peticiones cross-origin de HTTPS a HTTPS, y nada en degradaciones de HTTPS a HTTP. Es el mejor equilibrio entre privacidad, seguridad y funcionalidad. Los navegadores modernos (Chrome 85+, Firefox 87+) lo han adoptado como su valor por defecto incluso cuando no hay cabecera Referrer-Policy.
• unsafe-url: envía siempre la URL completa, sin importar el destino o el contexto de seguridad. Se llama "unsafe" por algo. Envía parámetros de consulta, rutas y todo lo demás incluso a destinos HTTP. Nunca lo uses a menos que tengas una necesidad muy concreta y entiendas los riesgos.

Implicaciones de privacidad de la cabecera Referer

La cabecera Referer es un problema de privacidad importante que muchos propietarios de sitios pasan por alto. Considera qué información pueden contener tus URLs:

• Consultas de búsqueda: si tu sitio tiene una función de búsqueda, la URL podría ser /search?q=tema+de+salud+sensible. Cualquier recurso externo cargado en la página de resultados recibe esa consulta.
• Identificadores de usuario: URLs como /usuario/juan-perez/perfil o /pedido/12345 filtran información del usuario y del pedido a terceros.
• Tokens y datos de sesión: algunas aplicaciones colocan tokens en las URLs para restablecimiento de contraseñas, confirmaciones de correo o enlaces compartidos. Estos podrían filtrarse a través de la cabecera Referer.
• Estructura interna de URLs: incluso solo la estructura de rutas (/wp-admin/, /solo-miembros/, /dashboard-interno/) revela información sobre la arquitectura de tu sitio.

Cada recurso de terceros en tu página es un posible receptor de esta información: Google Fonts, scripts de analítica, botones de redes sociales, vídeos incrustados, redes publicitarias, librerías alojadas en CDN e imágenes externas. Cada uno recibe la cabecera Referer con sus peticiones.

Relevancia para el RGPD y la protección de datos

Conforme al RGPD y a normativas de privacidad similares, las URLs que contienen identificadores personales o información sensible pueden constituir datos personales. Si tus URLs contienen nombres de usuario, direcciones de correo electrónico u otra información identificativa, compartir esas URLs vía la cabecera Referer con terceros podría suponer un problema de protección de datos.

Establecer una Referrer-Policy es una medida técnica directa que reduce la compartición innecesaria de datos con terceros. Aunque no es un requisito explícito del RGPD, encaja con los principios de minimización de datos (artículo 5.1.c) y privacidad desde el diseño (artículo 25). Si tu delegado de protección de datos o tu auditoría de privacidad pregunta qué medidas técnicas tienes para limitar la fuga de datos, una Referrer-Policy adecuada es un elemento concreto que puedes citar.

Comportamiento por defecto de WordPress y plugins habituales

El núcleo de WordPress no establece una cabecera Referrer-Policy por defecto. Esto significa que tu sitio depende de cuál sea el valor por defecto integrado en cada navegador. En los navegadores modernos, ese valor por defecto es strict-origin-when-cross-origin, que de hecho es una política razonable. Sin embargo, hay algunas cosas a tener en cuenta:

• Los navegadores antiguos pueden seguir teniendo por defecto no-referrer-when-downgrade, que envía la URL completa en todas las peticiones HTTPS a HTTPS.
• Establecer la cabecera explícitamente es mejor que confiar en los valores por defecto del navegador, porque comunica tu intención con claridad y cubre todas las versiones de navegador.
• Algunos plugins de seguridad de WordPress (como Sucuri o iThemes Security) incluyen una opción de Referrer-Policy en sus ajustes de hardening.
• WordPress 4.7.4 introdujo mejoras en la función wp_get_referer(), pero esta es una función del lado del servidor que lee la cabecera Referer para protección CSRF. No tiene relación con la cabecera de respuesta Referrer-Policy.

Impacto en la analítica del sitio web

La elección de tu Referrer-Policy afecta directamente a qué datos de referrer reciben tus herramientas de analítica, y a qué datos reciben otros sitios sobre el tráfico procedente del tuyo:

• Tu propia analítica: si usas Google Analytics, Matomo o una herramienta similar con un script de seguimiento en tu sitio, las peticiones del mismo origen siempre incluirán el referrer completo independientemente de la política (la mayoría de las políticas solo restringen los referrers cross-origin). Por tanto, los datos de tu analítica interna no se ven afectados por la mayoría de los valores de política.
• Seguimiento de tráfico entrante: la Referrer-Policy que estableces afecta a lo que ven otros sitios cuando tus visitantes vienen desde el tuyo. No afecta a lo que tú ves sobre el tráfico que llega a tu sitio (eso depende de la política del sitio que refiere).
• Seguimiento de afiliados y socios: si tienes un programa de afiliados o necesitas hacer seguimiento de clics salientes, una política muy restrictiva como no-referrer romperá el seguimiento basado en referrer. El recomendado strict-origin-when-cross-origin envía el origen (dominio) a los socios, lo que suele ser suficiente para la atribución.

Configurar Referrer-Policy en WordPress

El valor recomendado para la mayoría de sitios WordPress es strict-origin-when-cross-origin:

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

Para configurarlo en Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

En Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Mediante PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Si tu sitio gestiona datos especialmente sensibles (información médica, registros financieros, documentos legales), podrías plantearte una política más estricta como same-origin o no-referrer. Solo ten en cuenta que esto eliminará la información de referrer en todas las peticiones cross-origin, lo que puede afectar a servicios externos que dependan de ella.

Qué comprueba InspectWP

InspectWP comprueba si tu sitio WordPress envía una cabecera Referrer-Policy y reporta el valor configurado. Si la cabecera está ausente, tu sitio depende del valor por defecto del navegador de cada visitante, que varía entre versiones. Establecer una Referrer-Policy explícita garantiza un comportamiento coherente y demuestra que has tomado una decisión deliberada sobre cuánta información de URL comparte tu sitio con terceros. Para la inmensa mayoría de sitios WordPress, strict-origin-when-cross-origin es el valor recomendado.