因为当计算机科学家在 1990 年代初期提出 HTTP 协议时，他们认为包含一个referer字段是值得的（注意他们甚至拼错了英文单词 referrer），因此您可以跟踪谁在链接到您的网页——也许您想要回报并链接回来。

只有当您点击某个链接时才会发送它；例如，如果您在地址栏中复制或键入新 URL，则不会发送 HTTP Referer 字段。您应该注意，即使在您进行私人浏览时，许多 [all?] 浏览器仍会发送该referer字段，因为否则它们可能会破坏检查引用字段的网站。

限制跨域请求的同源策略仅指限制访问 DOM，特别是为了保护 cookie 和 javascript 无法控制别人的页面，除非特别允许。

跨域策略处理不在当前域/子域控制下的执行代码 - 例如，运行其他人的代码。这是一个安全问题。

将您的“推荐人”发送到另一个站点是一个隐私问题。您可以使用代理或浏览器插件来删除推荐信息。所以是的，一般来说，如果使用没有代理或插件的香草浏览器，这应该是隐私问题。

推荐信息有一些有用的用途，例如，如果您知道来自搜索引擎的 URL 是什么，您可以为用户突出显示文档中的搜索词。此外，它形成了一种限制访问的薄弱措施，但肯定很容易被欺骗。它是一种较弱的 CSRF 保护形式。

为什么这被认为是可以接受的？

并不是每个人都可以接受。这是隐私和实用性之间的糟糕妥协，被许多人视为历史错误。

换句话说，为什么Referer 标头不受跨域策略的约束？

Referer早于 Netscape 引入 JavaScript 和随之而来的同源策略。那时的网络是一个非常不同的地方，主要是公共静态文档和很少的交互。在这种环境下，URL 几乎不可能包含任何私有内容，本着公开引用的精神，让网络作者确切知道哪些文档链接到他们的文档似乎很有用。

也很明显，当时没有饼干。因此，如果您的浏览器告诉站点 A 您来自站点 B，那么站点 A 几乎无法处理该信息。它无法发现以前植入的 cookie 来将该引用信息与它所知道的有关您过去所做的任何其他信息联系起来，当然也不能让第三方 cookie 传播该信息以产生长期交叉- 像今天的谷歌一样的网站跟踪配置文件。

只有当现代“webapp”的功能集（包括脚本、cookie 和框架）结合在一起时，才变得很明显这Referer是错误的做法。如果它是今天设计的，我们最多会拥有类似于OriginCORS 的现代标头之类的东西，它具有稍微更隐私的站点名称，但没有路径/查询。

然而，足够多的网站（不明智地）依赖于Referer单个浏览器制造商无法轻易禁用该功能而不会对用户的兼容性产生负面影响。这使得修复变得非常困难。

引用者还用于防止图像等资源的“盗链”。如果您的请求的引用者与托管资源的域不匹配，那么您将被拒绝访问。