Disable/enabled hotlinking by Page rule


#1

Page rule should have an option to allow or disallow hotlinking for specific URL pattern.

Edit: From this page its say there used to be option to toggles Hotlink Protection on or off. but look like outdated because I can’t find these option in Page rule anymore.


#2

Thanks for bringing that article to our attention. I’ll get it updated to reflect current functionality.


#3

Out of interest - is this functionality still possible using one of the other options, such as turning off security etc?

It had never occurred to me until now but this would actually be very useful for me on one of my sites. (that is, enable domain-wide hotlink-protection, but disable it on a subset of images via a page rule).


#4

I’ve raised this internally for consideration, but in the meantime the best solution is to create an exclude folder and make sure all of the unprotected images live there.


#5

what’s the status of this? If it is an issue with adding the feature to the cloudflare dashboard or api; does hotlink protection respect our web server if we set a header?

Thanks for any info.


#6

It’s not currently planned, but I can pass along the feedback. Can you provide some more detail on your particular use case/need?


#7

The use case should be similar to the original poster. There is a subdomain I want to use to serve static content to use on another domain or different subdomain but this option causes problems. Yes there is a note creating a folder or grey cloud the domain. There is also the problem of browser implementation of same origin.

Giving us the option to disable this protection per dns entry will allow us to troubleshoot serving remote content without losing the benefit of using cloudflare in the first place.


#8

@user825 - If I understand you correctly, I have solved this issue using the new Firewall Rules. I have a clearly defined path to my static assets and block access to URLs containing that path where the referrer isn’t one of my ‘whitelisted’ domains. It’s working perfectly and only taking up one of my five precious free rules. These new Firewall Rules are absolutely awesome - solving so many little security things for me that used to be impossible or maybe even needed a Worker creating. You don’t get to use proper regex on the free tier but it’s can still keep things pretty tight if you lay your site out properly.


#9

sir, since a rep already confirms nothing was done; I honestly don’t know what you are talking since firewall rules have nothing to do with hotlink protection… Your hack is not desirable as it adds another level of complexity when a page rule is more appropriate or a header that will be respected; that can be configured on the web server.


#10

That’t not totally accurate. Nothing has been done regarding hotlink protection via Page Rules, but I believe there are a variety of workarounds that people could implement using Firewall Rules or even Workers.


#11

:wave: @user825,

You can certainly wait to see if Cloudflare eventually implements a mechanism to control this with page rules. However @saul’s solution appears to provide today a more robust and flexible solution than Cloudflare’s built in feature. It’s absolutely a viable solution to the problem and not a hack. Since Cloudflare caches static content, I’m unclear what a header on an origin server would solve for requests for cached requests, but you can certainly try that instead and let us know how it goes.

-OG


#12

@OliverGrant, thanks for that, I felt initially a little slighted by that reply when I was trying to be helpful.

You’re spot on - the new firewall Rules functionality are a far better way of implementing this and allow much more fine-grained control than I can ever foresee being introduced by way of additional config or new page rule options.

I’ve completely disabled the older Scrape Shield Hotlink protection on all my domains on the back of the fact that dong it properly with Cloudflare firewalling is just better all round. It does need a semblance of work getting things just right but the results are worth it. Same as anything really.


#13

There are a variety of workarounds that I already mentioned before firewall rules was mentioned but it is not a clear solution which is to disable a global feature enabled that impacts all enabled cloudflare sites. If you believe this is the solution than please update the faq on disabling hotlink protection.

@OliverGrant sir, obviously it seems you have never heard of X-Frame-Options or `
Content-Security-Policy: frame-ancestors". I kindly ask you stick on topic to a thread in the product requests category.


#14

:wave: @user825,

Firewall Rules are brand new, so it wasn’t an option when those other suggestions were made. And unlike those other suggestions a number of free rules are included with every plan type.

Great suggestion, I’ve done just that. Maybe @saul will include a nice screenshot of a sample rule or two for me to gussy it up.

https://www.pugflare.com/power-hotlink-protection/

Unsure how that relates, how is that going to prevent someone from directly hotlinking to a static asset? Oh right, it isn’t.

Ok, now that there is a great option to implement even more powerful hotlink protections using Firewall Rules I am sure this feature request will be given the priority it deserves. :laughing:

-OG


#15

The following is a simple example of the kind of possibilities now available via Firewall Rules. In this instance the assets under /assets are blocked unless they’re in a hotlink-ok subfolder (reproducing the old Scrape Shield exception, which was useful) or accessed from a list to white-listed sites (.org, .net etc) which appear in the referrer:

Naturally these can be extended and extended to be more restrictive. Personally I also enforce host name on which assets are accessed because mine are housed on a shared site as well as a few other thigns probably only specific to me and my requirements.


#16

@OliverGrant I am saddened that you think you are helping in a category intended to provide product requests to cloudflare to one where you are free to discuss your side issues with such fervor or impress me with your lack of understanding to what hotlinking protection is.

@saul thank you for expanding on your particular workaround.

@ryan I sincerely hope cloudflare’s solution to disabling hotlink protection on a particular subdomain to be so inelegant compared to the less elegant hotlink-ok option.


#17

The documentation has been updated to remove reference to hotlink protection as a page rule feature.

Looks like @saul has a method to do that using Firewall Rules. More complex logic can also be implemented via Workers.

Both Workers and Firewall rules were released after the initial feature request was made, so at least 2 things have been done by Cloudflare to provide the functionality to have more granular control and flexibility over hotlinking.


#18

@cscharff
Both Workers and Firewall rules were released after the initial feature request was made, so at least 2 things >have been done by Cloudflare to provide the functionality to have more granular control and flexibility over >hotlinking.

I honestly was am not looking for complex solutions which is a workaround for a one click global feature; apparently my initial problem in bumping this request. The workarounds would be unnecessary if implementing hotlink protection on the web server in the first place. My simplified and more to the point response should be:

Will this feature will be enabled for those who are using cloudflare more as a cdn than a full blown firewall.