Quick Summary
- Hotlink protection prevents external sites from using your server’s bandwidth to display images but can block social media shared link images.
- While hotlink protection stops direct embedding, it doesn’t prevent image theft or re-uploading to other servers.
- Social media services like Facebook need access to pull images directly from your server for shared links, typically via the og:image tag in Open Graph.
- Cloudflare offers a binary hotlink protection, but specific allowed domains can be set in server’s .htaccess or certain CDN services.
- For social media shared link images, allow referrers:
- Facebook: *.facebook.com, *.fbcdn.net
- Twitter: *.twitter.com, *.twimg.com
- LinkedIn: *.linkedin.com, *.licdn.com
- Ensure to include your own domain names and consider wildcard usage for various subdomains.
Hotlink protection is a useful way to prevent others from siphoning off your bandwidth by drawing the data for images from your server’s bandwidth.
It doesn’t prevent people from stealing your images—it just prevents them from embedding them on their site while pulling them directly from your server. It’s a method that’s also often referred to as leeching.
It also doesn’t stop them from just downloading the file and uploading it to their own site and serving it from there.
But there are times when you might want to use hotlink protection but still allow certain external domains to pull the images directly. Obviously, you want your own domains to be able to do this. But another situation I run into often is with images in shared links on social media services.
Hotlinking Images on Common Services
If you upload an image directly to a service such as Facebook, the image is uploaded and stored on Facebook’s servers and it’s completely separate from your own site and server. But with shared links, Facebook (or the other social media services) needs to be able to pull the image directly from your server. A common way to do this is through the og:image tag in Open Graph.
Cloudflare has a hotlink protection option under its Scrape Shield tab that takes a one-size-fits-all approach. That is, it’s either on or off, and you don’t have any option to fine-tune the allowed domains. But you can be more specific either on your server’s .htaccess file or through some CDN services that give you the option to set allowed referrers.
On KeyCDN, for instance, you do it through the Zone Referrers section.
On BunnyCDN, you can find the Allowed Referrers option under the Security category. 1
Below are the referrers I’ve been using to allow social media shared link images. I’m posting this mostly for my own reference, and I certainly can’t guarantee that the list is comprehensive or that all of these are actually necessary. But this list has been working for me, so maybe it’ll be useful as a starting point for someone else.
Facebook:
- *.facebook.com
- *.fbcdn.net
Twitter:
- *.twitter.com
- *.twimg.com
Linked In:
- *.linkedin.com
- *.licdn.com
Notes
I’m using wildcards here in place of hard-coded subdomains because these services tend to have multiple CDN subdomains they can pull from.
I haven’t included Instagram because you can’t share links there, so it’s not going to be pulling the images from your domain.
Don’t forget to add your own domain names as well.
The way that wildcards are used here doesn’t include the root domain, so you might need to add those, too.
Related Posts
- One issue I’ve run into with BunnyCDN s that it doesn’t appear to support empty referrers—or at least have an option to enable support for them, as KeyCDN has. That seems to block some authentic search engine bots and thus lead to 403 errors. You only run into this issue if you have any Allowed Referrers set. If you leave that blank, there are no restrictions in place.[↩]
