引用站点计谋（Referrer Policy）
引用站点计谋（Referrer Policy）是HTTP相应头中的一个安全相关字段，用于控制在用户从一个页面导航到另一个页面时，是否以及如何发送 referrer 信息。Referrer 是指当前页面的上一个页面的 URL，通过这个字段可以追踪用户的泉源。默认环境下，浏览器会将完备的 referrer URL 发送给目标页面，这可能包罗敏感信息如登录凭证或个人数据。为了保护用户隐私和安全，网站管理员可以通过设置 Referrer-Policy 来控制 referrer 的内容和发送方式。
Referrer-Policy 可以有多种不同的值，每种值对应不同的计谋：
[*]no-referrer：不发送任何 referrer 信息，这是最宽松且最不安全的计谋。
[*]no-referrer-when-downgrade：当协议安全性低落（比方从 HTTPS 转到 HTTP）时不发送 referrer 信息。
[*]origin：只发送当前页面的 origin 部门（协议、主机和端口），而不包括路径和查询字符串。
[*]origin-when-cross-origin：跨域请求时只发送当前页面的 origin 部门，同源请求则发送完备的 referrer URL。
[*]same-origin：仅在同源请求时发送完备的 referrer URL。
[*]strict-origin：与 origin 相似，但不允许发送虚伪的 referrer 信息。
[*]strict-origin-when-cross-origin：跨域请求时只发送当前页面的 origin 部门，且不允许发送虚伪的 referrer 信息。
[*]unsafe-url：允许发送完备的 referrer URL，但可能会袒露敏感信息。
Referrer-Policy 的设置可以通过以下几种方式实现：
[*]在 HTTP 相应头中直接设置 Referrer-Policy 字段。
[*]使用 meta 标签指定 name 值为 referrer 的属性。
[*]在 a、area、img、iframe 或 link 元素上使用 referrerpolicy 属性。
[*]使用 Link 关系中的 noreferrer 属性。
通过公道配置 Referrer-Policy，网站全部者可以在保护用户隐私和提高安全性之间找到平衡点，防止恶意运动，并遵守相关法规要求。
Referrer-Policy 的最新尺度和最佳实践是什么？
Referrer-Policy（引用泉源计谋）的最新尺度和最佳实践主要集中在如何控制浏览器在请求中包罗引用泉源信息的方式，以增强网站的安全性和隐私保护。根据，新版的Referrer Policy规定了五种计谋：No Referrer、No Referrer with Origin、Same Origin、No Referrer When Downgrading、 always。这些计谋旨在限制或完全不发送引用泉源信息，以防止敏感数据泄露。
最佳实践方面，指出，对于自身服务器，通过客户端发来的请求中带有的referer信息可以用来防止CORS（跨站请求伪造）。然而，为了更好地防御CSRF攻击，最佳实践应该是结合多种防御步伐，包括但不限于设置合适的Referrer-Policy计谋。
具体到Referrer-Policy的使用，提供了团结国网络安全尺度化机构（UN-ETSI）的发起，即可以通过修改链接的referrerpolicy属性来限制引用泉源信息的传播，比方设置为"origin"以仅传递当前页面的域名部门，或者使用noreferrer属性来克制浏览器自动设置Referer头。
如何在不同范例的网站（如电商、论坛、博客）中实行 Referrer-Policy 以保护用户隐私？
在不同范例的网站中实行Referrer-Policy以保护用户隐私，需要根据网站的具体需求和场景选择合适的计谋。以下是一些基于搜刮效果的发起：
[*] 电商网站：对于电商网站，保护用户隐私尤为重要，由于可能涉及支付信息和购物历史。可以使用strict-origin-when-cross-origin计谋，这在跨域请求时只发送泉源的域名（不包括路径），从而减少敏感信息的泄露。
[*] 论坛：论坛通常包罗大量用户生成内容，保护用户隐私同样重要。可以采用no-referrer或no-referrer-when-downgrade计谋，这些计谋在大多数环境下不会发送Referrer头，但在降级（从HTTPS到HTTP）时会发送完备的URL，这有助于防止跟踪但同时保留了肯定水平的统计功能。
[*] 博客：博客网站可能需要肯定的统计功能来分析访问量和用户行为。可以使用same-origin计谋，这仅在同源请求时发送Referrer头，适用于大多数博客场景，既能满意统计需求又不过分袒露用户隐私。
[*] 通用计谋：无论哪种范例的网站，都可以考虑使用严格模式（如strict origin或strict-origin-when-cross-origin），这些计谋在跨域请求时只发送泉源的域名，有用防止了跨站跟踪。
[*] 配置方法：可以通过设置HTTP相应头中的Referrer-Policy，或者在HTML文档中通过<meta name="referrer" content="...">标签来指定Referrer计谋。
Referrer-Policy 对SEO（搜刮引擎优化）有何影响？
Referrer-Policy（引荐泉源政策）对SEO（搜刮引擎优化）有明显影响，主要体现在以下几个方面：
[*] 增强网页结构和可读性：通过在和标签中使用Referrer-Policy属性，可以提供一种语义化的方式来描述链接的目标，这不仅增强了网页的结构和可读性，同时也对搜刮引擎优化（SEO）有着积极的影响。
[*] 控制Referrer信息传递：Referrer-Policy允许网站管理员定义出站链接中的referrer头信息的值。这意味着可以控制在用户点击链接时发送给目标网站的referrer信息，从而影响目标网站的分析工具和SEO计谋。
[*] 加密流量与referrer数据共享：通过meta referrer tag，可以更好地控制如何传递referrer信息，即使是在使用HTTPS的环境下，也可以将referrer数据传递给全部网站，包括那些使用HTTP的网站。这有助于保持流量的加密同时保留HTTPS的全部好处，对于SEO来说是一个重要的考虑因素。
[*] 影响网站访问量和回访率：参考源站点计谋可以帮助提高网站的访问量。搜刮引擎可能会忽略那些与网站目标不符或目标不明确的网站，而从参考源站点访问的客户通常具有较高的回访率。
Referrer-Policy通过控制referrer信息的传递，影响网站分析工具的使用，以及通过参考源站点计谋提高网站访问量和回访率，从而间接地对SEO产生积极影响。
在现实应用中，Referrer-Policy 导致的安全毛病有哪些例子？
在现实应用中，Referrer-Policy 导致的安全毛病主要体现在以下几个方面：
[*] CSRF（跨站请求伪造）攻击：
[*]通过修改或埋伏请求的Referer字段，攻击者可以绕过安全验证。比方，在2007年Gmail的CSRF毛病中，攻击者可以或许埋伏乃至修改本身请求的Referer。
[*]另一个案例是单点登录网站通过Referer偷取用户授权，这表明攻击者可以通过操控Referer字段来窃取用户的会话信息和cookie，从而模仿合法用户执行利用。
[*] 不安全的访问控制：
[*]应用程序使用HTTP Referer头作为访问控制决议的基础。比方，一个应用程序可能严格控制对主要管理菜单的访问权限，但当用户请求某个特定的管理功能时，它可能会查抄该请求是否来自管理菜单页面，并假设用户已经访问过该页面并因此拥有所需的权限。这种模型存在根本性缺陷，由于Referer头完全由用户控制，可以设置为任何值。
[*] 恶意内容或跨站脚本攻击：
[*]设置不当的Referrer-Policy可能导致浏览器提供的安全特性失效，从而允许恶意内容或跨站脚本攻击。
[*] 隐私泄露：
[*]如果没有正确设置Referrer-Policy，浏览器可能会发送过多的用户信息给服务器，导致隐私泄露。
Referrer-Policy 在现实应用中的不当配置可能导致多种安全毛病，包括CSRF攻击、不安全的访问控制、恶意内容或跨站脚本攻击以及隐私泄露等题目。
如何测试和验证 Referrer-Policy 的有用性？
要测试和验证 Referrer-Policy 的有用性，可以采取以下步调：
[*] 使用HTML剖析器查抄：根据，可以通过HTML剖析器来查抄是否设置了 Referrer-Policy。这通常通过在网页的元标签中查找<meta referrer>来实现。如果存在这样的标签，而且其内容与预期的 Referrer-Policy 值匹配，则可以以为 Referrer-Policy 已被正确设置。
[*] 查抄HTTP相应头中的Referrer-Policy：提到，服务器对HTTP请求的相应头中应包罗Referrer-Policy。如果在相应头中找到并确认了正确的Referrer-Policy值，则可以验证其有用性。
[*] 浏览器API的请求对象属性：根据，可以使用Web APIs中的Request接口的referrerPolicy只读属性来获取请求的Referrer-Policy。这允许开辟者在客户端代码中查抄和验证Referrer-Policy是否按预期工作。
[*] 现实利用测试：创建一个测试页面，尝试从不同的源加载资源，并观察浏览器如那里理Referrer头部。比方，从同一域名加载页面时，应看到Referrer头部包罗当前页面的URL；而从不同域名加载时，Referrer头部可能为空或不包罗任何信息，这取决于所使用的Referrer-Policy计谋。
[*] 跨站请求伪造（CSRF）攻击测试：根据，可以通过模拟跨站请求来测试Referrer-Policy的有用性。如果Referrer-Policy可以或许克制或限制这些请求，那么它就有用地防止了潜伏的安全威胁。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]