大型API提供商如何实际执行域名白名单机制？

核心校验逻辑：不是单靠请求头，而是多重验证组合 #

大多数像Google Maps、Facebook登录、Font Awesome Pro这类API的域名白名单机制，根本不是只看请求里的Referer或Origin头，而是结合了身份凭证+域名校验的双重甚至多重验证：

• 首先，你必须拥有该API的专属密钥/Token（比如Font Awesome Pro的项目token），所有合法请求都需要携带这个凭证；
• 其次，服务器会同时校验请求的Referer/Origin是否在你配置的白名单内，并且这个凭证是和你的白名单域名绑定的。

针对Font Awesome Pro的盗用疑问：实际很难实现 #

你担心恶意访客知道你的域名后伪造请求盗用资源？其实完全不用慌：

1. 浏览器同源策略限制：如果恶意用户在自己的网站里尝试加载Font Awesome Pro资源，浏览器会自动带上他们自己域名的Referer头，服务器一看不在你的白名单里，直接拦截。
2. Token与域名绑定：就算有人从你的页面拿到了Token，他们用这个Token发起请求时，服务器会检查请求的来源域名是否在你设置的白名单中——不在的话，哪怕Token是对的也没用。
3. 手动伪造请求的局限性：用curl之类工具手动改Referer头确实能骗过域名校验，但这类API的服务器会验证Token的合法性，没有合法的Token，请求根本通不过。

为什么HTTP请求伪造看起来容易，却绕不过白名单？ #

你觉得HTTP请求容易伪造，是因为只看到了请求头可以手动修改，但这类商业API的白名单机制是一套完整的防护体系：

• 浏览器的同源策略会限制前端跨域请求随意篡改Origin/Referer，这是第一道防线；
• 专属凭证（Token/密钥）与域名的绑定是第二道防线，就算绕过了头的校验，没有对应凭证也白搭；
• 部分API还会加入请求签名机制，把请求参数、域名、时间戳等信息一起生成签名，服务器收到请求后会重新计算签名比对，这种情况下伪造请求的成本极高，几乎不可能实现。

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