How can I prevent Amazon Cloudfront from hotlinking?

Question

I use Amazon Cloudfront to host all my site's images and videos, to serve them faster to my users which are pretty scattered across the globe. I also apply pretty aggressive forward caching to the elements hosted on Cloudfront, setting Cache-Controlto public, max-age=7776000.

I've recently discovered to my annoyance that third party sites are hotlinking to my Cloudfront server to display images on their own pages, without authorization.

I've configured .htaccessto prevent hotlinking on my own server, but haven't found a way of doing this on Cloudfront, which doesn't seem to support the feature natively. And, annoyingly, Amazon's Bucket Policies, which could be used to prevent hotlinking, have effect only on S3, they have no effect on CloudFront distributions [link]. If you want to take advantage of the policies you have to serve your content from S3 directly.

Scouring my server logs for hotlinkers and manually changing the file names isn't really a realistic option, although I've been doing this to end the most blatant offenses.

Breadroot

Answer 1

You can forward the Referer header to your origin

1. Go to CloudFront settings
2. Edit Distributions settings for a distribution
3. Go to the Behaviors tab and edit or create a behavior
4. Set Forward Headers to Whitelist
5. Add Referer as a whitelisted header
6. Save the settings in the bottom right corner

Make sure to handle the Referer header on your origin as well.

Coaxial

I can only add Origin, Access-Control-Request-Headers and Access-Control-Request-Methods to the white list... Also the linked document doesnt say anything explicitly about the referer... – Narrative

@BernhardVallant You should be able to see the option here. If not then it's probably because of the price plan you're on. – Book

@Coaxial can you show an example for the last part of handling the referer header on the origin? – Rivard

@Rivard that's different per server you run on the origin. Google will point you to code samples for that if you search for prevent hotlinking nginx or prevent hotlinking apache. – Coaxial

@Coaxial thanks I did google myself into another dimension, but was going down the wrong path. What I was confused about is where this referer check was as there are origin settings in cloudfront etc. In my head I would think the referer check would simply be on cloudfront itself. But I understand now we add the check like a normal hotlink protection on our actual server as referer header is now forwarded to our server. – Rivard

Don't do this. If the image being requested is already in the cache from a 'legit' user fetching it, a hotlinking client will be able to request it just fine (and you're still paying for the cloudfront hit). If a hotlinking client does manage to get a cache miss and the request goes to your origin and is denied, then cloudfront will cache the 403 response for some amount of time, causing legit clients to also get this response when they request that item. Sorry to revive this years old answer, but it's a top search result still. – Satanism

@Satanism I think you're mistaken, "You can configure CloudFront to forward headers to the origin, which causes CloudFront to cache multiple versions of an object based on the values in one or more request headers." see docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/… – Coaxial

Interesting, so it sounds like this will work. Thanks for the correction. – Satanism

Answer 2

We had numerous hotlinking issues. In the end we created css sprites for many of our images. Either adding white space to the bottom/sides or combining images together.

We displayed them correctly on our pages using CSS, but any hotlinks would show the images incorrectly unless they copied the CSS/HTML as well.

We've found that they don't bother (or don't know how).

Ornament

Answer 3

The official approach is to use signed urls for your media. For each media piece that you want to distribute, you can generate a specially crafted url that works in a given constraint of time and source IPs.

One approach for static pages, is to generate temporary urls for the medias included in that page, that are valid for 2x the duration as the page's caching time. Let's say your page's caching time is 1 day. Every 2 days, the links would be invalidated, which obligates the hotlinkers to update their urls. It's not foolproof, as they can build tools to get the new urls automatically but it should prevent most people.

If your page is dynamic, you don't need to worry to trash your page's cache so you can simply generate urls that are only working for the requester's IP.

Almetaalmighty

Thanks Jonas: that's a rather convoluted procedure, though? – Breadroot

How would I go about accessing the requesters ip when generating signed urls? – Honeysucker

Answer 4

As of Oct. 2015, you can use AWS WAF to restrict access to Cloudfront files. Here's an article from AWS that announces WAF and explains what you can do with it. Here's an article that helped me setup my first ACL to restrict access based on the referrer.

Basically, I created a new ACL with a default action of DENY. I added a rule that checks the end of the referer header string for my domain name (lowercase). If it passes that rule, it ALLOWS access.

After assigning my ACL to my Cloudfront distribution, I tried to load one of my data files directly in Chrome and I got this error:

Outfox

Answer 5

As far as I know, there is currently no solution, but I have a few possibly relevant, possibly irrelevant suggestions...

First: Numerous people have asked this on the Cloudfront support forums. See here and here, for example.

Clearly AWS benefits from hotlinking: the more hits, the more they charge us for! I think we (Cloudfront users) need to start some sort of heavily orchestrated campaign to get them to offer referer checking as a feature.

Another temporary solution I've thought of is changing the CNAME I use to send traffic to cloudfront/s3. So let's say you currently send all your images to:

cdn.blahblahblah.com (which redirects to some cloudfront/s3 bucket)

You could change it to cdn2.blahblahblah.com and delete the DNS entry for cdn.blahblahblah.com

As a DNS change, that would knock out all the people currently hotlinking before their traffic got anywhere near your server: the DNS entry would simply fail to look up. You'd have to keep changing the cdn CNAME to make this effective (say once a month?), but it would work.

It's actually a bigger problem than it seems because it means people can scrape entire copies of your website's pages (including the images) much more easily - so it's not just the images you lose and not just that you're paying to serve those images. Search engines sometimes conclude your pages are the copies and the copies are the originals... and bang goes your traffic.

I am thinking of abandoning Cloudfront in favor of a strategically positioned, super-fast dedicated server (serving all content to the entire world from one place) to give me much more control over such things.

Anyway, I hope someone else has a better answer!

Dialectal

Thanks so much for those comments. Sounds like there's no proper solution to this right now. manually changing URLs is feasible but pretty labour-intensive! I hope Amazon come up with a better way. – Breadroot

If you change the CNAME, you don't need to change the URLs. And you can use 301 redirects to catch referrals from the old CNAME, for a time, before you change to a new CNAME (to tell search engines where you've gone). If anyone's reading this and wondering what I mean by the CDN CNAME, it's explained very well in Paul Stamatiou's guide "How to: Getting Started with Amazon Cloudfront" [paulstamatiou.com/…, which is the simplest, clearest guide to implementing a Cloudfront CDN I've found. – Dialectal

I like the DNS suggestion, periodically knock out all the hotlinks :) – Blah

Answer 6

This question mentioned image and video files.
Referer checking cannot be used to protect multimedia resources from hotlinking because some mobile browsers do not send referer header when requesting for an audio or video file played using HTML5.
I am sure of that about Safari and Chrome on iPhone and Safari on Android.
Too bad! Thank you, Apple and Google.

Granth

Answer 7

How about using Signed cookies ? Create signed cookie using custom policy which also supports various kind of restrictions you want to set and also it is wildcard.

Barbicel