Stop the Madness: Redirect those Ridiculous Favicon 404 Requests

.htaccess made easy

For the last several months, I have been seeing an increasing number of 404 errors requesting “favicon.ico” appended onto various URLs:

When these errors first began appearing in the logs several months ago, I didn’t think too much of it — “just another idiot who can’t find my site’s favicon..” As time went on, however, the frequency and variety of these misdirected requests continued to increase. A bit frustrating perhaps, but not serious enough to justify immediate action. After all, what’s the worst that can happen? The idiot might actually find the blasted thing? Wouldn’t that be nice..

But no, the 404 favicon errors just won’t go away. Last week, as I was digging through my site’s error logs, there were hundreds of these infamous favicon requests — line after line of moronic URL activity, scripted directory brachiation targeting the all-empowering favicon exploit. Give me a break. Finally, I just couldn’t deal with it any more and decided to put an end to the madness..

Pssst: it’s in the root directory

Fortunately, stopping this nonsense is relatively easy. My knee-jerk reaction was to simply block all requests for favicon.ico:

<IfModule mod_alias.c>
 RedirectMatch 403 favicon.ico

..very effective; 29 characters and problem solved. I could even add this line to my 3G Blacklist, but I don’t want to prevent direct access to my real favicon, so an alternate strategy is required. Let’s try it again, this time invoking the mind-boggling powers of Apache’s mod_rewrite:

<ifmodule mod_rewrite.c>
 RewriteCond %{THE_REQUEST} favicon.ico [NC]
 RewriteRule (.*) [R=301,L] 

Ahh, much better. With this code placed in your site’s root blog’s subdirectory 1 HTAccess file, all requests for your site’s favicon.ico file will be directed to the original location, as specified in the RewriteRule. First line: check for the proper Apache module (mod_rewrite); second line: match any request for favicon.ico (regardless of casing); third line: rewrite all matched requests as and declare the redirect as permanent (301); last line: close the module-check container.

I have been using this code for about a week now and have seen no further 404 errors for misdirected favicon requests. Filtering out the noise from my error and access logs makes it easier to identify more serious issues.

Finally, in case you were wondering about the identity of the ruthless favicon bandit, here you go:

 order allow,deny
 allow from all
 deny from   "# favicon bandit zombie "
 deny from  "# favicon bandit zombie "
 deny from  "# favicon bandit zombie "
 deny from   "# favicon bandit zombie "
 deny from "# favicon bandit zombie "

These are all coming from completely different hosts, however blocking them for the immediate future may provide some temporary relief against any other cracker nonsense (i.e., non-favicon exploits) executed through these zombie machines.

And that’s a wrap. If you are experiencing similar 404 favicon requests, I would be interested in hearing about them. As always, thank you for your generous attention :)


  • 1 It has been discovered that the redirection method described in this article works only when placed in a subdirectory, such as would be the case for blogs installed in their own directory. When placed in the root directory, this code will create an infinite redirection loop. For more information, and to learn about a similar technique that works in all directories (including the root directory) check out my article, Redirect All Requests for a Nonexistent File to the Actual File.