Super Plugin Sale! Your Choice: BOGO or 30% Off »
Web Dev + WordPress + Security

Stop the Madness: Redirect those Ridiculous Favicon 404 Requests

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 subdirectory1 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 root) check out Redirect All Requests for a Nonexistent File to the Actual File.

About the Author
Jeff Starr = Web Developer. Book Author. Secretly Important.
USP Pro: Unlimited front-end forms for user-submitted posts and more.

10 responses to “Stop the Madness: Redirect those Ridiculous Favicon 404 Requests”

  1. You got a real writting talent Jeff; I so enjoyed the first part of the post. This introduction was awesome!

    Now about the very problem of your favicon, I must say I find absolutely no sense in asking for a favicon everywhere. I can imagine that the zombie machine crawles the web searching for favicons, and that its worm is very badly coded so that it search by adding “favicon.ico” to the current document URL.

    But anyway, for what purpose? Is there some kind of sick genius trying to make the internet implode by stealing every and each favicon? No seriously, I can’t see any reason of parsing the internet for favicons.

  2. Thank you, Louis! It helps to have such excellent readers — makes it very easy to stay inspired and focused. So thanks to you as well :)

    And for the favicon issue — that’s just it: it seems like an absolute waste of resources to be scanning for vulnerabilities via favicon.ico. It’s like, “what’s the point?” I would love to know the purpose and/or reasoning for this nonsense, but until that happens, it’s the best I can do to stop the madness with a little htaccess magic!

  3. I get that alot as well; i traced it a few times was actually coming from yahoo.

    Their bot is acting up I think; Ah well file it away for 4g:p

  4. How incredibly timely. I just got a notice from my hosting provider that I am consuming way too many cycles (or whatever they call it). Their analysis is showing lots of these weird favicon requests, as well as a bunch for a specific image at a bunch of weird URL’s. I gotta try this .htaccess trick to see if it works. I’ll email you with some specifics.

  5. Jeff Starr 2008/08/12 2:42 pm

    @Donace: not surprising, as I have posted several times on this site, Yahoo’s sloppy Slurp crawler can’t seem to play by the rules. And, funny you should mention 4G.. ;)

    @Chris: check your email! :)

  6. Callum Mckay 2008/08/27 2:18 pm


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

    This seems to upset Firefox by putting it into a loop. I used this instead.

    RewriteRule ^favicon.ico$ /images/favicon.ico

  7. Jeff Starr 2008/09/01 9:24 am

    Hi Callum, depending on the location of the htaccess code, infinite loops may be an issue. Glad to see you worked it out for yourself (and thanks for sharing the code, btw), but for others who may be experiencing the same problem, check out this folow-up article I posted after encountering the same thing on another one of my sites:

    Redirect All Requests for a Nonexistent File to the Actual File

    There, I explain the method in detail and provide an alternate technique that may be used anywhere on your site.

  8. Firefox is utterly anal about favicons for some reason.

    My LAN XAMPP Apache logs are saturated with these 404s, because my compatibility regime obviously includes… Firefox!

    Btw, for folks that don’t have a localhost LAMP (Apache, MySQL, PHP) or similar running, it would scare you sh*tless if you knew the amount of time your server spends writing to its error logs (most of which you can’t easily access on a shared package).

  9. Thank you thank you thank you! I get hundreds of these every week! Problem solved.

  10. Jeff Starr 2009/04/29 9:38 am

    My pleasure, Bernard — glad to be of service! :)

Comments are closed for this post. Something to add? Let me know.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
Digging Into WordPress: Take your WordPress skills to the next level.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.