En qué casos HTTP_REFERER estará vacío

Sé que es posible obtener un HTTP_REFERER vacío. ¿Bajo qué circunstancias sucede esto? Si obtengo uno vacío, ¿siempre significa que el usuario lo cambió? ¿Obtener uno vacío es lo mismo que obtener uno vacío? ¿Y bajo qué circunstancias me sale eso también?

Estará / puede estar vacío cuando el usuario final

• ingresó la URL del sitio en la barra de direcciones del navegador.
• visitó el sitio mediante un marcador mantenido por el navegador.
• visitó el sitio como primera página en la ventana / pestaña.
• hizo clic en un enlace en una aplicación externa.
• cambió de una URL https a una URL http.
• cambió de una URL https a una URL https diferente.
• tiene instalado un software de seguridad (antivirus / firewall / etc.) que despoja al referente de todas las solicitudes.
• está detrás de un proxy que despoja al referente de todas las solicitudes.
• visitó el sitio mediante programación (como curl ) sin establecer el encabezado de referencia (¡searchbots!).

HTTP_REFERER: enviado por el navegador, indicando la última página que vio el navegador.

Si confía en [HTTP_REFERER] por algún motivo importante, no debe hacerlo, ya que puede falsificarse fácilmente:

1. Algunos navegadores limitan el acceso para no permitir que se pase HTTP_REFERER
2. Escriba una dirección en la barra de direcciones no pasará el HTTP_REFERER
3. abrir una nueva ventana del navegador no pasará HTTP_REFERER, porque HTTP_REFERER = NULL
4. tiene algún complemento de navegador que lo bloquea por razones de privacidad. Algunos firewalls y AV lo hacen.

Pruebe esta extensión de Firefox, podrá configurar los encabezados que desee:

@ Maestro de celebración:

Firefox

extensiones: refspoof , refontrol , modificar encabezados , sin referencia

Deshabilitar completamente: la opción está disponible en about: config en "network.http.sendRefererHeader" y desea establecer esto en 0 para deshabilitar el pase del árbitro.

Google Chrome / Chromium:

extensiones: noref , spoofy , noreferrer externo

Deshabilite completamente: Chnage ~ / .config / google-chrome / Default / Preferences o ~ / .config / chromium / Default / Preferences y configure esto:

{
   ...
   "enable_referrers": false,
   ...
}

O simplemente agregue --no-referrers al acceso directo o en cli:

google-chrome --no-referrers

Ópera:

Deshabilite completamente: Configuración> Preferencias> Avanzado> Red, y desmarque "Enviar información de referencia"

Servicio web de suplantación de identidad:

http://referer.us/

Proxy de filtrado independiente (falsificación de cualquier encabezado):

Privoxy

Spoofing http_referer cuando se usa wget

'--referer = url'

Spoofing http_referer cuando se usa curl

-e, - referencia

Spoofing http_referer con telnet

telnet www.yoursite.com 80 (press return)
GET /index.html HTTP/1.0 (press return)
Referer: http://www.hah-hah.com (press return)
(press return again)

La lista de BalusC es sólida. Una forma adicional en que este campo aparece frecuentemente vacío es cuando el usuario está detrás de un servidor proxy. Esto es similar a estar detrás de un firewall, pero es un poco diferente, así que quería mencionarlo en aras de la integridad.

También estará vacío si se utiliza el nuevo borrador estándar de la Política de referencia para evitar que el encabezado de referencia se envíe al origen de la solicitud. Ejemplo:

<meta name="referrer" content="none">

Aunque Chrome y Firefox ya han implementado una versión borrador de la Política de referencia, debe tener cuidado con ella porque, por ejemplo, Chrome espera en no-referrerlugar de none(y he visto también en neveralguna parte).

He encontrado que la implementación del navegador de referencia es realmente inconsistente.

Por ejemplo, un elemento de anclaje con el atributo "descargar" funciona como se esperaba en Safari y envía el referente, pero en Chrome el referente estará vacío o "-" en los registros del servidor web.

<a href="http://foo.com/foo" download="bar">click to download</a>

Está roto en Chrome: no se envió ningún árbitro.