Origin 标头的定义说：
origin-or-null = origin / %s"null" ; case-sensitive
“null”是否像域名一样管理？换句话说，当使用“null”时（至少在某些情况下），服务器是否可以接受请求，或者它一直被认为是一个错误？
我在Fetch Documentation 中寻找了解释，但到目前为止我还没有找到这个特定问题的答案。
【问题讨论】：
标签： http cors cross-domain
通过发送Origin: null 标头，浏览器表明请求来自opaque origin。也就是说，浏览器向作为服务器维护者的您发出信号，表明请求不是从实际在 Web 上运行的应用程序以典型方式发起的，并且使用 Ajax 方法或 Fetch 或 XHR 调用您的服务器 - 所以它可能不是您实际上希望您的服务支持的用例。
所以在响应Origin: null 请求时，您通常不希望发送Access-Control-Allow-Origin 响应标头。换句话说，您希望浏览器阻止任何前端 JavaScript 代码访问您针对此类请求发回的响应。
虽然浏览器将Origin 标头设置为null 的最常见情况可能是从某人的本地文件系统（从file:// URL，而不是从Web 服务器）运行前端代码时——那里还有许多其他情况，浏览器还将Origin 标头设置为null。如需详尽列表，请参阅https://stackoverflow.com/a/42242802/441757。
https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null 解释了您应该如何看待这种情况：
返回
Access-Control-Allow-Origin: "null"似乎是安全的，但是任何使用非分层方案（例如data:或file:）的资源的 Origin 的序列化被定义为“null” .许多用户代理将授予此类文档访问带有Access-Control-Allow-Origin: "null"标头的响应的权限，并且任何来源都可以创建具有“空”来源的恶意文档。因此应该避免 ACAO 标头的“null”值。
换句话说，如果您有意允许来自服务器的响应在运行在某人的本地文件系统上的前端 JavaScript 代码中使用（例如，对于进行本地测试的人）。但是这样做，您将不仅允许本地文件系统的情况，而且还允许https://stackoverflow.com/a/42242802/441757 中描述的所有其他情况。要么全有，要么全无。
【讨论】：