Prevent hotlinking without mod_rewrite

An alternative for those who can't use mod_rewrite

[jdMorgan]

We get a lot of posts in this forum asking for help in blocking hotlinking, or at least making it more difficult. The usual approach is to use mod_rewrite [httpd.apache.org]:

RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain\.com [NC]
RewriteRule \.(gif¦jpe?g¦png)$ - [NC,F]

which blocks hotlink access with a 403-Forbidden response, or alternatively:

RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain\.com [NC]
RewriteCond %{REQUEST_URI} !^/alternate_image\.
RewriteRule \.(gif¦jpe?g¦png)$ /alternate_image.$1 [L]

which serves an alternate image of the same filetype as requested (which you must provide).

However in a few cases, it turns out that some hosting providers don't trust their users or can't provide support for the (admittedly) potentially-complex problems that can arise when using mod_rewrite. Many low-cost hosting providers simply can't afford to support such a compact, complex, powerful 'language' as mod_rewrite, especially since it relies on another compact, complex, powerful element -- Regular Expressions [etext.lib.virginia.edu].

For those Webmasters stuck with such a situation, there is another possible simple solution, and that is to use mod_setenvif [httpd.apache.org] and mod_access [httpd.apache.org] instead of mod_rewrite. In many cases, hosting providers that don't support mod_rewrite *do* allow users to use these other modules. Mod_setenvif is available only on Apache 1.3 and later, and there are several restrictions on mod_setenvif previous to Apache 1.3.13 -- See the Apache mod_setenvif documentation cited above for the (numerous) details.

The following code accomplishes exactly the same thing as the first mod_rewrite code example above, and is the best you can do with mod_setenvif and mod_access; The option of serving an alternate image can't be supported by these modules.

<FilesMatch "\.(gif¦jpe?g¦png)$">
SetEnvIfNoCase Referer ^$ allow_image
SetEnvIfNoCase Referer ^http://(www\.)?mydomain\.com allow_image
Order Deny,Allow
Deny from all
Allow from allow_image
</FilesMatch>

Notes on these examples:

In all examples above, access is allowed if the request has an HTTP_REFERER that is within your own domain or is blank. It is necessary to allow blank referrers because the presence ot the HTTP_REFERER header in an HTTP request is not reliable -- Many corporate and ISP caching proxies, firewalls, and "Internet Security" software packages block the HTTP_REFERER header, often without the user being aware of it. Be aware that blocking blank referrers may result in your spending a lot of time with "customer support" issues. If you feel you must block blank referrers, I suggest using a cookies-based method to control access, rather than one of these simple referrer-based methods.

I used the FilesMatch [httpd.apache.org] directive in the third code example. FilesMatch is only available on Apache 1.3 and later. Since support for mod_setenvif is also only available in Apache 1.3 and later, this should be a non-issue.

Some of the code above is case-sensitive with respect to the filenames. With mod_rewrite, you can add code to handle each filetype independently with case-correction, or add additional mod_rewrite rules to correct the case of the file extensions before processing the code above, if necessary. (I'm trying to limit the scope of discussion here; If you are careful about writing your links to always use consistent-case URIs, this should not be a problem anyway.)

Posting on this forum causes the code to be modified. Specifically, the forum software deletes single spaces ahead of exclamation points "!" and changes the solid vertical pipe character to a broken vertical pipe "¦" character. You must examine all code posted here and make corrections as needed before attempting to use the code.

The above examples are just that - examples. They may contain typos. They are certainly not suitable for all possible applications, and you should expect to need to modify them to suit your specific needs. Time spent studying the documentation linked above is worthwhile.

If none of the above anti-hotlinking solutions are supported by your server or adequate for your needs, there remain the options of using cookies to control access or redirecting all image requests to a PERL or PHP script for processing.

Jim