从另一台服务器下载时，即使Access-Control-Allow-Origin设置为all（*），HTML5下载属性也不起作用

乜昆

2023-03-14

问题内容：

我有这样的下载链接：

<a href="foo.xls" download="bar.xls">Foobar</a>

在同一台服务器上下载文件时，此方法工作正常，但从另一台服务器（在本例中为Azure blob存储）下载文件时，即使HTTP响应返回以下标头，文件名仍为“
foo.xls”：

访问控制允许来源：*

这是设计使然，还是我可以将其他标头添加到HTTP响应中以使其正常工作？

问题答案：

是的，这是设计使CORS标头对download属性没有影响。只有两种支持该download属性的浏览器，即Firefox和Chrome，并且两种浏览器对跨域文件都有不同的策略。

实际上，65之前的 Chrome版本确实允许download跨域文件中的属性，而没有CORS标头，但Firefox却选择了不允许，理由是潜在的社交工程攻击。

MDN download在a标记的属性部分下记录了Firefox 20的此行为，此行为至今未更改。

在Firefox 20中，仅对具有相同来源的资源的链接授予此属性。

Bugzilla的这份报告讨论了安全问题以及使用CORS的可能性。

当用户单击这样的链接时，将提示用户是否要下载。用户似乎很容易犯错，以为是在下载原始网站上的内容，而不是从bank.com上下载的内容。

如果您对跨源安全性提出质疑，是否可以在考虑到相同来源和CORS（访问控制允许来源）的情况下实现它？这对于Web应用程序非常有用（使用JS创建Blob并让用户使用一些有意义的名称下载它）

Google反对为此使用CORS。

还有这个Bugzilla报告，该报告总结了其他bug报告中的决策。

另外，跨源下载在Google Chrome中也可以正常运行。

是的，我们认为他们这样做是在添加安全漏洞。

Bugzilla问题似乎并未排除download将来使用CORS进行跨域属性支持的可能性，但现在使用CORS标头对download属性没有任何作用。如果其他浏览器开始支持该属性，则可能会达成共识。

为了完整起见，当然有Content-Disposition标头，您可以使用该标头来强制从其他域下载，但这并不提供与download属性相同的功能。它确实具有更好的浏览器支持。