PHP | .htaccess file | How to prevent image bandwidth theft with .htaccess

 Here is the article. 

How to Prevent Image Bandwidth Theft With .htaccess

by Christopher Heng, thesitewizard.com

If your website displays beautiful pictures, you may encounter the ugly situation where your photos and other images are used without your permission on other sites. Even worse, those websites "hotlink" your pictures, that is, they don't host the pictures directly on their site, but embed them into their pages by linking to the copy on your site. This way, not only do they infringe your copyright, but they also make you pay for their bandwidth.

System Requirements

The solution outlined in this article requires your site to be hosted on a machine using the Apache web server. In addition, your web host must allow you to override the server's configuration using a .htaccess file. For the more technically inclined, it uses the facilities provided in the mod_setenvif Apache module.

If this is not the case for your website, you cannot use the suggestions given here. You might wish to use my alternative solution, a PHP script that block image bandwidth thieves instead.

(To find out if your web server fulfills the requirements stated here, try checking up the documentation on your web host's website — the information is usually available on their list of web hosting packages, price lists or on their order form. Alternatively, contact their technical support and find out from them.)

Steps to Take

Protecting your images using a .htaccess file is trivial.

1. Put all the images you wish to protect from being stolen (bandwidth-wise) in a separate directory.

2. Create an ASCII text file named .htaccess and save it in that directory. Note that the name starts with a fullstop ("period" in US English) and is entirely in small letters (ie, lowercase). Cut and paste the following lines into that file:

   SetEnvIfNoCase Referer "^http://www.example.com/" locally_linked=1
   SetEnvIfNoCase Referer "^http://www.example.com$" locally_linked=1
   SetEnvIfNoCase Referer "^http://example.com/" locally_linked=1
   SetEnvIfNoCase Referer "^http://example.com$" locally_linked=1
   SetEnvIfNoCase Referer "^https://www.example.com/" locally_linked=1
   SetEnvIfNoCase Referer "^https://www.example.com$" locally_linked=1
   SetEnvIfNoCase Referer "^https://example.com/" locally_linked=1
   SetEnvIfNoCase Referer "^https://example.com$" locally_linked=1
   SetEnvIfNoCase Referer "^$" locally_linked=1
   <FilesMatch "\.(gif|png|jpe?g)$">
     Order Allow,Deny
     Allow from env=locally_linked
   </FilesMatch>
   

   Change "example.com" to your real domain name. If your site can be accessed using other domain names (eg "www.example.net"), be sure to add an additional SetEnvIfNoCase line for each of those domain names (with the URLs appropriately changed to the addresses of your domains. On the other hand, if your site can only be accessed using one domain, for example, using only "www.example.com", feel free to delete the non-www versions, although it is probably a good idea to leave it there in case you ever change your mind in the future. The cut and paste code above caters to the usual case where most sites can be accessed with or without the "www" prefix. It also works whether your site is accessed with HTTPS or plain HTTP.

   Do not correct my spelling in the code snippet given above. "Referer" (with only one "r" in the middle of the word) is the word that needs to go into the .htaccess file — do not change it to "Referrer". Yes, I know the spelling is wrong in every single variant of English. Unfortunately, that spelling error was built into various Internet software in ancient times, and cannot be changed now since too many sites depend on it being spelt this way. (It's the problem faced by popular software: the programmers can't fix mistakes they made in the past, because everyone now depends on that mistake working exactly as it used to.)

That's all there is to it. The above file should protect all images that have ".gif", ".png", ".jpg" and ".jpeg" extensions.

Remember to use an ASCII text editor (also known as "text editor" or "plain text editor") to create the .htaccess file. Do not use Microsoft Word or Wordpad. Notepad (found on all Windows systems) is fine.

Explanation: .htaccess to Block Unauthorized Image Usage

Whenever a browser sends your web server a request for an image, it usually also sends the URL of the page that linked to that image. The above .htaccess file causes the server to check this URL (via mention of "Referer" in the above snippet) and if it is one of the authorized URLs that you specify, it will set an internal flag called "locally_linked". This internal flag is technically called an "environmental variable". If the URL sent is not in this list of authorised URLs, the flag (or environment variable) is not set. Note that we also set the "locally_linked" variable if the browser does not send any URL at all: this occurs when the visitor accesses your site using a browser or a proxy that suppresses the referring URL.

The web server then checks if the file requested has an extension in the list given above (gif, png, jpg and jpeg). If so, and the "locally_linked" variable is set, it will send the image. Otherwise it an error will be sent.

What Happens When A Bandwidth Thief Links to Your Image

After you create the .htaccess file, if some other site tries to link to your image from their site, they will find that the image will not display on their site. On the other hand, your images should generally load fine on pages on your site.

Potential Problems

Like the PHP solution, this method relies on the HTTP_REFERER header being properly sent by the visitor's browser to your site. Some browsers, anonymous surfing proxies and personal firewalls allow the user to change what is sent. These software or proxies may thus (potentially) transmit HTTP_REFERER headers with some user-specified value.

When this occurs, the image will not appear even when the visitor is on your site (which means that your own page will have broken link images), or it may appear even when it is displayed on the thief's site.

Hopefully the percentage of people who encounter this is small, but be aware that these situations do occur.