HTTP Referer 教程

作者: 阮一峰

日期: 2019年6月 4日

HTTP 请求的头信息里面,Referer 是一个常见字段,提供访问来源的信息。

很多开发者知道这个字段,但是说不清它的具体细节。本文详细介绍该字段。

一、Referer 的含义

现实生活中,购买服务或加入会员的时候,往往要求提供信息:"你从哪里知道了我们?"

这叫做引荐人(referrer),谁引荐了你?对于公司来说,这是很有用的信息。

互联网也是一样,你不会无缘无故访问一个网页,总是有人告诉你,可以去那里看看。服务器也想知道,你的"引荐人"是谁?

HTTP 协议在请求(request)的头信息里面,设计了一个Referer字段,给出"引荐网页"的 URL。

这个字段是可选的。客户端发送请求的时候,自主决定是否加上该字段。

很有趣的是,这个字段的拼写是错的。Referer的正确拼写是Referrer,但是写入标准的时候,不知为何,没人发现少了一个字母r。标准定案以后,只能将错就错,所有头信息的该字段都一律错误拼写成Referer

二、Referer 的发生场景

浏览器向服务器请求资源的时候,Referer字段的逻辑是这样的,用户在地址栏输入网址,或者选中浏览器书签,就不发送Referer字段。

主要是以下三种场景,会发送Referer字段。

(1)用户点击网页上的链接。

(2)用户发送表单。

(3)网页加载静态资源,比如加载图片、脚本、样式。


<!-- 加载图片 -->
<img src="foo.jpg">
<!-- 加载脚本 -->
<script src="foo.js"></script>
<!-- 加载样式 -->
<link href="foo.css" rel="stylesheet">

上面这些场景,浏览器都会将当前网址作为Referer字段,放在 HTTP 请求的头信息发送。

浏览器的 JavaScript 引擎提供document.referrer属性,可以查看当前页面的引荐来源。注意,这里采用的是正确拼写。

三、Referer 的作用

Referer字段实际上告诉了服务器,用户在访问当前资源之前的位置。这往往可以用来用户跟踪。

一个典型的应用是,有些网站不允许图片外链,只有自家的网站才能显示图片,外部网站加载图片就会报错。它的实现就是基于Referer字段,如果该字段的网址是自家网址,就放行。

由于涉及隐私,很多时候不适合发送Referer字段。

这里举两个例子,都不适合暴露 URL。一个是功能 URL,即有的 URL 不要登录,可以访问,就能直接完成密码重置、邮件退订等功能。另一个是内网 URL,不希望外部用户知道内网有这样的地址。Referer字段很可能把这些 URL 暴露出去。

此外,还有一种特殊情况,需要定制Referer字段。比如社交网站上,用户在对话中提到某个网址。这时,不希望暴露用户所在的原始网址,但是可以暴露社交网站的域名,让对方知道,是我贡献了你的流量。

四、rel属性

由于上一节的原因,浏览器提供一系列手段,允许改变默认的Referer行为。

对于用户来说,可以改变浏览器本身的全局设置,也可以安装浏览器扩展。这里就不详细介绍了。

对于开发者来说,rel="noreferrer"属性是最简单的一种方法。<a><area><form>三个标签可以使用这个属性,一旦使用,该元素就不会发送Referer字段。


<a href="..." rel="noreferrer" target="_blank">xxx</a>

上面链接点击产生的 HTTP 请求,不会带有Referer字段。

注意,rel="noreferrer"采用的是正确的拼写。

五、Referrer Policy 的值

rel属性只能定制单个元素的Referer行为,而且选择比较少,只能发送或不发送。W3C 为此制定了更强大的 Referrer Policy

Referrer Policy 可以设定8个值。

(1)no-referrer

不发送Referer字段。

(2)no-referrer-when-downgrade

如果从 HTTPS 网址链接到 HTTP 网址,不发送Referer字段,其他情况发送(包括 HTTP 网址链接到 HTTP 网址)。这是浏览器的默认行为。

(3)same-origin

链接到同源网址(协议+域名+端口 都相同)时发送,否则不发送。注意,https://foo.com链接到http://foo.com也属于跨域。

(4)origin

Referer字段一律只发送源信息(协议+域名+端口),不管是否跨域。

(5)strict-origin

如果从 HTTPS 网址链接到 HTTP 网址,不发送Referer字段,其他情况只发送源信息。

(6)origin-when-cross-origin

同源时,发送完整的Referer字段,跨域时发送源信息。

(7)strict-origin-when-cross-origin

同源时,发送完整的Referer字段;跨域时,如果 HTTPS 网址链接到 HTTP 网址,不发送Referer字段,否则发送源信息。

(8)unsafe-url

Referer字段包含源信息、路径和查询字符串,不包含锚点、用户名和密码。

六、Referrer Policy 的用法

Referrer Policy 有多种使用方法

(1)HTTP 头信息

服务器发送网页的时候,通过 HTTP 头信息的Referrer-Policy告诉浏览器。


Referrer-Policy: origin

(2)<meta>标签

也可以使用<meta>标签,在网页头部设置。


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

(3)referrerpolicy属性

<a><area><img><iframe><link>标签,可以设置referrerpolicy 属性。


<a href="..." referrerpolicy="origin" target="_blank">xxx</a>

七、退出页面重定向

还有一种比较老式的技巧,但是非常有效,可以隐藏掉原始网址,谷歌和 Facebook 都在使用这种方法。

链接的时候,不要直接跳转,而是通过一个重定向网址,就像下面这样。


<a  href="/exit.php?url=http%3A%2F%2Fexample.com">Example.com</a>

上面网址中,先跳转到/exit.php,然后再跳转到目标网址。这时,Referer字段就不会包含原始网址。

(完)

留言(20条)

referer 之前的理解就是个简单的来源,从哪里过来方法的。知识点挺多的, Referrer Policy 这个特定的情况是很有用的。

游览器是不是不能直接修改Referrer为想要的值,只能设置是不是发送或者发送的方式~~

好详细,感觉学到了,谢谢阮老师

要是能把文章顺便也做个视频版就好了,好像有人说从文字到视频,信息接受效率逐渐递减,而娱乐性则逐渐提高。所以,对于一些干货太足的课程和书籍,辅以图文和音频视频等多种表现形式,更能激发大家的学习兴趣,取得更好的学习成果。从文字到图文,再到音频和视频,供给侧需要付出的精力是逐渐递减的。写一本书需要系统思考,写一篇文章需要灵光一现,音频只需要随口侃大山(目前市场主流的音频生产形式大都需要以逐字稿为基础,然后再录制成音频),而视频则只需要在脑海中勾勒一副大致框架便可以录制。

关于 referrer 有个事情很有意思。
早期各大搜索引擎的 referrer 都是带有搜索词信息的,因此网站可以很明确地知道用户是通过哪些关键词搜索并且访问到了站点。后来百度说是有安全隐患,率先取消了 referrer 显示,不久后搜狗、360 也纷纷跟进。目前网站想知道 referrer 信息只能通过百度云的搜索关键词 API,调用费是 1000 次 1 元。

有的反爬虫机制好像就是使用了referer.如果你的referer不是本网站,那就不能爬取。

c语言标准库里的库函数creat(),拼写也是错的。为什么? 就是第一作者不小心搞错了,没有为什么。

引用vdust.leo的发言:

c语言标准库里的库函数creat(),拼写也是错的。为什么? 就是第一作者不小心搞错了,没有为什么。

原来如此,我一直跟着写错。

写得很详细,受教了

典型应用 exhentai

引用Bob的发言:


原来如此,我一直跟着写错。

Java标准库的Hashtable也是,按照命名规则,应该是HashTable才对.由于写错了,所以一直都只能按照错误的写.

引用Gin的发言:

关于 referrer 有个事情很有意思。
早期各大搜索引擎的 referrer 都是带有搜索词信息的,因此网站可以很明确地知道用户是通过哪些关键词搜索并且访问到了站点。后来百度说是有安全隐患,率先取消了 referrer 显示,不久后搜狗、360 也纷纷跟进。目前网站想知道 referrer 信息只能通过百度云的搜索关键词 API,调用费是 1000 次 1 元。

目前谷歌有类似调用API吗

form 标签应该没有rel的这个属性

写的很详细,Referer noreferrer 还是相当有用的

引用Rustin的发言:

form 标签应该没有rel的这个属性

有什么依据?我也确实只在博主这里看到这个属性

引用Rustin的发言:

form 标签应该没有rel的这个属性

已确认可以的,博主是正确的
由于表单提交功能的存在,form 标签与 a 标签一样,可以导致页面跳转行为,从而导致 opener 和 referrer 等安全隐患。

为了解决这一问题,form 标签也增加了 rel 属性支持,从而可以通过设定 noopener、noreferrer 等行为来规避安全风险。

看这段话的意思,是不久前才加入的

有几个问题,盼解答:
1)document.referrer和header中的referrer是不是一定是完全一样的?
2)点击微信中的链接打开的页面,referrer为空,有没有什么办法可以甄别这些从微信中来的流量?
3)在开发者工具中查看时,有很多资源的header中没有referrer字段,这是为什么呢?

referer其实可以理解为“经手人”这一概念,我们访问某些资源图片都是网站经手的,通过对referer来源进行限定可以防止资源被盗用。
我一开始的想法是通过限制IP来实现这个功能,但发现自己是陷入了思维误区,因为访问图片资源实际上的请求方是浏览器,将访问IP限定为仅允许本机根本毛用没有

在chrome中测试,form加上 rel="noreferrer"属性。浏览器发送请求时,request header仍然带了referer

引用congcong的发言:

在chrome中测试,form加上 rel="noreferrer"属性。浏览器发送请求时,request header仍然带了referer

貌似支持性问题吧,Safari OK

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接