Question about Cloudflare hotlink protection?


#1

hey i have question, i turned ON hotlinking picture protection in Cloudflare! but how can i know if its working ?

i tried to embed picture from my website in another blog (i test it with BLOGGER free)

but i can see picture in that blog! how supposed protection to work ? i thought i can see picture in blog, like IMGUR did if they blacklist website to not hotlink picture, if u embed their pictures in ur website u will get black picture. i hope someone can explain to me


#2

#3

The following line from the above-linked article is interesting:

In other words, HTTP Referers that are not in-zone and not blank will be denied access. Supported file extensions are gif, ico, jpg, jpeg, and png.

The “and” vs “or” is making me try to work out the logic. I’m pretty sure an out-of-zone referrer wouldn’t be blank, so that’s just redundant. In other words, blank refers will be allowed access.


#4

But unless one actually requires a set referrer all the referrer based hotlinking protection schemes will stop working more and more as time goes on


#5

I read that reply in the other thread and I had difficulty keeping the servers/clients straight in my mind.

I think you’re saying that for protection to work, everybody needs to pass along Referrers. Correct?


#6

Yes, this sort of prevention of embedded resources by third parties (vulgo hotlinking) is traditionally based on the referrer. Historically, browsers always sent the referrer, unless configured not to do by the user. As the latter was rather the exception, it usually worked by checking whether the referrer contained a legitimate host or nothing at all and let it only pass if these conditions were met.

Now, “recent” *) browser versions extended that control from just the user to the world of HTML and in doing so allow third parties to embed resources without having the usual referrer being sent, which in turn means the aforementioned approach (expecting an illegitimate host when embedded) wont work any longer.

I guess at this point the only viable way to address that issue is to always expect a referrer and never accept an empty field. That however will also mean all legitimate requests without a referrer would be blocked (e.g. direct requests for the resource, requests from browsers configured not to send the referrer, etc.).

Apologies if I over-explained :slight_smile:

*) Seems to go back already three to five years.


#7

This topic was automatically closed after 14 days. New replies are no longer allowed.