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

Disable Trace and Track for Better Security

The shared server on which I host Perishable Press was recently scanned by security software that revealed a significant security risk. Namely, the HTTP request methods TRACE and TRACK were found to be enabled on my webserver. The TRACE and TRACK protocols are HTTP methods used in the debugging of webserver connections.

Although these methods are useful for legitimate purposes, they may compromise the security of your server by enabling cross-site scripting attacks (XST). By exploiting certain browser vulnerabilities, an attacker may manipulate the TRACE and TRACK methods to intercept your visitors’ sensitive data. The solution, of course, is disable these methods on your webserver.

How to disable the TRACE and TRACK methods

To disable TRACE and TRACK HTTP methods on your Apache-powered webserver, add the following directives to either your main configuration file or root HTAccess file:

RewriteEngine on
RewriteRule .* - [F]

These directives disable the TRACE and TRACK methods via the following process:

  • RewriteEngine on — enables Apache’s rewrite module (this directive is not required if already present in your htaccess file)
  • RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) — targets all TRACE and TRACK request methods for the following rule
  • RewriteRule .* - [F] — return a 403 Forbidden error response for all matched conditions (i.e., all TRACE and TRACK methods)

With these rules in place, your site is protected against one more potential security vulnerability :)

About the Author
Jeff Starr = Creative thinker. Passionate about free and open Web.
GA Pro: Add Google Analytics to WordPress like a pro.

27 responses to “Disable Trace and Track for Better Security”

  1. Hey Jeff,

    Is the below code best practice for .htaccess files?

    RewriteEngine on
    RewriteRule .* - [F]


    – Dean (Sydney, Australia)

  2. Jeff Starr 2009/09/06 9:19 pm

    Hi Dean,

    As far as I know.. I certainly try to post only “best-practice” code, but I have been known to make mistakes, from time to time. Is there something specific that causes you to question?

  3. Rick Beckman 2009/09/06 10:34 pm

    Hey, Jeff, thanks for the code. I’m running on Dreamhost, and they provide the ability to have an account-wide .htaccess file — an .htaccess file that is processed for every domain on a user’s account — and some things work in this file, others don’t.

    This code at least doesn’t crash my site — some perfectly valid code, when used in the account-wide file, does crash things — but I’m not sure if it’s actually working.

    Do you know of a way to test those request methods against a site?

  4. Rick Beckman 2009/09/06 10:37 pm

    Oh, never mind, I’m just dense. I tested it by adding in the GET method as well. It didn’t block requests, so I’ll have to do this the long way, adding to each of my domain’s .htaccess files.

    Here’s a request: Work up a tutorial on how to modify one .htaccess file and have it reflected across as many other files as desired (via Shell/cron/whatever), making sure that site-specific code (such as WP’s permalink code) isn’t touched. So, for example, a “# Account-wide declarations” block could be copied to each file automatically. That sure would be handy!

  5. How do you check whether TRACE and TRACK are enabled or disabled?

  6. Thomas Scholz 2009/09/07 2:28 am

    I recommend to add DELETE to the list:


  7. Jeff Starr 2009/09/07 8:28 am

    @Rick: Good idea, but remember that .htaccess functions in cascading fashion, such that placing any directives in your root directory will — unless told otherwise — be applied to all subsequent subdirectories.

    @duck: You could either ask your host or telnet to your domain with the following commands:

    TRACE / HTTP/1.1 [enter]
    Host: yourdomain.tld [enter]

    The first line of the result will be the response code.

    @Thomas: Good call. I will update the article.

  8. Rick Beckman 2009/09/07 8:43 am

    I know that, Jeff. What I’d like to be able to do is apply a variety of security functions to all of my domains (each reside in its own directory within my home directory), and manually updating each domain’s .htaccess to account for new security rules is tedious. Being able to update them all in one go would be awesome.

  9. Jeff Starr 2009/09/07 9:28 am

    Ah, gotcha. On some server setups you can apply .htaccess directives to directories above the web root. So for example, if you have the following directory tree:


    You would simply create an .htaccess file in your /home/ or /public_html/ directory to have it’s rules applied to all subdirectories (i.e., your different domains).

    Alternately, if you have access to your server configuration file, you could place your directives there and have them applied to everything in one fell swoop.

  10. Rick Beckman 2009/09/07 11:47 am

    I can create such an .htaccess file — it works with the allow/deny rules and various other things, but mod_rewrite doesn’t work for it.

    And unfortunately, on Dreamhost regular hosting, no access to real config files. :S

  11. Okay, one more thing to try that may help. Many shared hosts have their accounts setup with a primary domain, which is generally the one specified during account creation. In many cases, the root folder for the primary domain is the /public_html/ (or equivalent) directory itself, such that its .htaccess file applies to all domains.

    I’m guessing that you may have already tried this, but if not, mod_rewrite should work in the .htaccess file of that directory.

    Otherwise, a script that updates server-wide .htaccess files would be difficult to create, especially because you only want to target the .htaccess files in each root directory. This is certainly possible with even PHP or something, however it would require your .htaccess files to be writable, which may not be the best strategy.

  12. Rick Beckman 2009/09/07 8:57 pm

    Nah, there isn’t a primary domain. The structure of my account looks like this when I log in via FTP:


    Each individual domain’s folder is the root folder for that domain (i.e., there isn’t a child public_html/ or www/ or anything of that nature), and each domain’s folder (and all subsequent children) can have fully-functional .htaccess files.

    The / directory itself, though, is a bit limited. It’s above the Web root, so mod_rewrite doesn’t seem to work — either that’s the reason, or it just isn’t enabled that high up.

    I do, however, maintain all of my configuration files (wp-config.php files, for example) in the / directory, so what I may end up doing is writing a security PHP script that checks user-agents, IPs, requests, and so on. Then all I’d need to do is include it at the top of the wp-config.php file.

    That method likely won’t be *as* quick as .htaccess (and definitely not as quick as the http.conf file), but it will be slightly quicker than maintaining it all as an actual WordPress plugin as the included security file would launch almost immediately on page access.

    That’ll be a stop-gap. I’m going to look at how WordPress generates .htaccess rules, modifying.htaccess files in such a way as to not modify any other custom-added content… I might be able to write a PHP script that, when one, copies one .htaccess file to as many others as I want.

    By default on my server, PHP can modify just about any files — I rarely have to CHMOD anything — and whether that’s a bad thing or not, I dunno. It is danged convenient for me, though. If I ever get something workable, I’ll share the code.

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 »
Banhammer: Protect your WordPress site against threats.
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.