.NET Core多租户场景下使用HTTP Referer头的可靠性疑问

首先明确：HTTP Referer头完全不可靠，不能作为多租户识别的核心依据，以下是常见的Referer头无数据或不完整的场景：

• 直接访问：用户在浏览器地址栏直接输入API地址、通过书签打开请求，或是客户端（如APP、脚本）直接发起的请求，这类场景没有前置跳转页面，不会携带Referer。
• 隐私保护机制：主流浏览器的隐私模式、各类隐私保护插件（如AdBlock、Privacy Badger）会主动屏蔽Referer头，避免用户行为被追踪。
• HTTPS转HTTP的跨协议请求：如果请求发起页面是HTTPS协议，而目标API是HTTP协议，浏览器会自动移除Referer头，防止敏感信息泄露。
• 跨域请求限制：跨域场景下，若未正确配置Referrer-Policy响应头，浏览器可能仅发送源域名（而非完整Referer），甚至完全不发送Referer头。
• 客户端主动移除：移动端APP、Postman等调试工具、爬虫脚本等，开发者可以手动移除Referer头，这类请求自然不会携带。
• 安全设备拦截：企业防火墙、反病毒软件、网络代理等安全设备，可能会过滤掉Referer头。

更可靠的多租户身份识别方案 #

既然HttpContext.Request.Host无法使用，推荐以下几种更稳定的方案：

• 自定义请求头：约定客户端携带X-Tenant-Id或X-Tenant-Domain这类自定义头，服务端直接读取解析，这是可控性最高的方案。
• JWT Token嵌入租户信息：在签发的JWT Token payload中加入租户ID/域名，服务端验证Token时同时解析租户标识，安全性和可靠性都很高。
• 客户端证书：适用于内部或高安全要求的场景，通过客户端证书的字段（如Subject）来标识租户，服务端验证证书后提取信息。
• 查询参数（不推荐）：虽然可以在URL中附加?tenant=xxx，但容易被篡改，且不符合RESTful规范，仅作为临时应急方案。

内容的提问来源于stack exchange，提问作者Elham Kohestani