我使用 Amazon Cloudfront 来托管我网站的所有图像和视频，以便更快地为分散在全球各地的用户提供服务。我还将非常积极的前向缓存应用于托管在 Cloudfront 上的元素，设置Cache-Control为public, max-age=7776000.
最近让我烦恼的是，第三方网站未经授权就热链接到我的 Cloudfront 服务器以在他们自己的页面上显示图像。
我已经配置.htaccess为防止在我自己的服务器上进行热链接，但在 Cloudfront 上没有找到这样做的方法，它似乎本身不支持该功能。而且，令人讨厌的是，Amazon 的存储桶策略（可用于防止盗链）仅对 S3 有效，对 CloudFront 分配没有影响 [链接]。如果您想利用这些策略，您必须直接从 S3 提供您的内容。
搜索我的服务器日志以查找热链接器并手动更改文件名并不是一个现实的选择，尽管我一直在这样做以结束最公然的罪行。
欢迎大家提出意见。
确保也处理您的来源上的 Referer 标头。
官方方法是为您的媒体使用签名网址。对于您要分发的每个媒体片段，您可以生成一个特制的 url，该 url 在给定的时间和源 IP 约束下工作。
静态页面的一种方法是为该页面中包含的媒体生成临时 url，其有效期为页面缓存时间的 2 倍。假设您的页面的缓存时间是 1 天。每隔 2 天，链接就会失效，这要求热链接者更新其 url。这不是万无一失的，因为他们可以构建工具来自动获取新网址，但它应该阻止大多数人。
如果您的页面是动态的，则无需担心会破坏页面的缓存，因此您可以简单地生成仅适用于请求者 IP 的 url。
我们遇到了许多盗链问题。最后，我们为许多图像创建了 css sprites。要么在底部/侧面添加空白，要么将图像组合在一起。
我们使用 CSS 在我们的页面上正确显示了它们，但是任何热链接都会错误地显示图像，除非它们也复制了 CSS/HTML。
我们发现他们不打扰（或不知道如何）。
自 2015 年 10 月起，您可以使用 AWS WAF 来限制对 Cloudfront 文件的访问。这是来自 AWS 的一篇文章，它宣布了 WAF 并解释了您可以使用它做什么。这是一篇帮助我设置我的第一个 ACL 以根据引用者限制访问的文章。
基本上，我创建了一个默认操作为 DENY 的新 ACL。我添加了一条规则，检查我的域名（小写）的引用标头字符串的结尾。如果它通过该规则，则它允许访问。
将 ACL 分配给 Cloudfront 发行版后，我尝试直接在 Chrome 中加载我的一个数据文件，但出现此错误：
据我所知，目前没有解决方案，但我有一些可能相关，可能不相关的建议......
第一：许多人在 Cloudfront 支持论坛上提出过这个问题。例如，请参见此处和此处。
显然，AWS 受益于盗链：点击次数越多，他们向我们收取的费用就越多！我认为我们（Cloudfront 用户）需要启动某种精心策划的活动，以让他们提供推荐人检查作为一项功能。
我想到的另一个临时解决方案是更改用于将流量发送到 cloudfront/s3 的 CNAME。因此，假设您当前将所有图像发送到：
cdn.blahblahblah.com（重定向到一些 cloudfront/s3 存储桶）
您可以将其更改为 cdn2.blahblahblah.com 并删除 cdn.blahblahblah.com 的 DNS 条目
作为 DNS 更改，这将在他们的流量到达您的服务器附近之前击倒所有当前进行热链接的人：DNS 条目将无法查找。您必须不断更改 cdn CNAME 才能使其生效（比如每月一次？），但它会起作用。
这实际上是一个比看起来更大的问题，因为这意味着人们可以更轻松地刮取您网站页面（包括图像）的整个副本 - 所以不仅仅是您丢失的图像，而不仅仅是您为提供这些图像而付费。搜索引擎有时会得出结论，您的页面是副本，而副本是原件……然后您的流量就会爆炸。
我正在考虑放弃 Cloudfront，转而使用具有战略定位的超快速专用服务器（从一个地方向全世界提供所有内容），让我对这些事情有更多的控制权。
无论如何，我希望其他人有更好的答案！
使用签名 cookie 怎么样？使用自定义策略创建签名 cookie，该策略还支持您要设置的各种限制，并且它是通配符。
这个问题提到了图像和视频文件。
由于某些移动浏览器在请求使用 HTML5 播放的音频或视频文件时不发送referer 标头，因此无法使用Referer 检查来保护多媒体资源免遭盗链。
我确信 iPhone 上的 Safari 和 Chrome 以及 Android 上的 Safari。
太糟糕了！谢谢你，苹果和谷歌。