Disable Trace and Track for Better Security

♦ Posted by Jeff Starr in .htaccess, Security

Updated August 8, 2024 • 27 comments

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
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
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 = Web Developer. Book Author. Secretly Important.

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

Jeff Starr 2009/09/07 9:11 pm • Post Author

Yes, definitely share the code if you end up with something. If I had the time, I would try to script something that did the job, but my free time is unbelievably scarce these days. It is difficult to choose among the many opportunities and possibilities that are available on the Web. If only I could clone myself..

John Hoff - WP Blog Host 2009/09/07 11:29 pm

Looks like this is in the 4G Blacklist. I just checked my .htaccess file and there it was. Cool.

Thanks – sent out a tweet.

Jordan Ogren 2009/09/08 7:38 am

I have the following in my .htaccess from the 4G Blacklist:

# FILTER REQUEST METHODS
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>

I am assuming, like John Hoff, that this has me covered. Am I correct?

Jeff Starr 2009/09/08 8:09 am • Post Author

Hi John, yep the 4G Blacklist includes these directives, so you’re covered. Thanks for the tweet :)

Hi Jordan, yes you are good to go. The reason for this article was to help those who may not have the 4G installed.

Thomas Scholz 2009/09/08 10:14 am

Jordan, remove HEAD from your list. This is a Good Thing.

Let’s say, someone checks the links on his website to find and remove outdated URLs: His script will use HEAD to verify that the linked pages are still there. If your response code isn’t 200 the link will probably be removed.

Forbidding HEAD means forbidding links from well maintained web sites.

Jordan Ogren 2009/09/08 11:54 am

@Jeff and @Thomas,

Thanks guys, I really appreciate your shared knowledge.

Jeff Starr 2009/09/08 11:50 am • Post Author

I may have to agree with Thomas here. The HEAD request method was blocked in the 4G Blacklist to help thwart referrer spam and other malicious exploits. At the time, there seemed to be no benefits to keeping the HEAD method, so it was blocked.

With Thomas’ hypothetical link-checking scenario, there may be reason to permit HEAD requests after all. This was something that I hadn’t thought of, but it certainly seems like a valid scenario. I will probably remove the HEAD block from the next, 5G Blacklist.

In this case, I think the pros of allowing outweigh the pros of blocking.

Greg 2009/09/08 3:13 pm

Pretty agree with Thomas too, for the HEAD.
But HEAD can also help to find the server version, if the owner set the server signature off.

Nan 2009/09/27 7:51 am

Hi Jeff! I would like to add this to my htaccess:

# FILTER REQUEST METHODS

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]

But I have already:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Can I have 2 or 3 different in the same htaccess?

Also, you say to put: RewriteRule .* - [F] and Jordan put: RewriteRule ^(.*)$ - [F,L] So what does the L stand for? Should I put it or not?

Thank you so much for your tips!!

Jeff Starr 2009/10/06 10:14 am • Post Author

Hi Nan, you can definitely add multiple blocks of HTAccess code into the same .htaccess file. It should work perfectly fine.

For the [L] flag, it simply means that the rule is the “Last” rule for that particular set of directives. This is one way of keeping the different rulesets separate and distinct from one another.

So yes, if you have multiple sets of rules, as in your case, you would want to include the [L] flag to keep everything distinct.

I hope this helps!

Abraham 2010/09/04 4:58 am

Limiting the allowed HTTP methods is great, but I think a whitelist approach is better :

RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET|POST)$ [NC]
RewriteRule .* - [F,L]

If a developer then specifically requires another method in his program (eg. PUT), deliberate action is required to enable it, which he should only take if he understands the need and implications.

Abraham 2010/09/07 12:19 pm

I ran some tests on (the servers of) my preferred hosting provider, and discovered that the TRACE method still isn’t being disabled, even though a whitelist approach disables everything else (except the whitelisted methods of course)!!

I’ve contacted them about it but thought I’d leave a comment here just to remind everyone to test (any and all) code once it’s in place, to make sure the code does what it’s supposed to!

Hope it helps someone.

Comments are closed for this post. Something to add? Let me know.

Jeff Starr 2009/09/07 9:11 pm • Post Author

Yes, definitely share the code if you end up with something. If I had the time, I would try to script something that did the job, but my free time is unbelievably scarce these days. It is difficult to choose among the many opportunities and possibilities that are available on the Web. If only I could clone myself..
John Hoff - WP Blog Host 2009/09/07 11:29 pm

Looks like this is in the 4G Blacklist. I just checked my .htaccess file and there it was. Cool.

Thanks – sent out a tweet.
Jordan Ogren 2009/09/08 7:38 am

I have the following in my .htaccess from the 4G Blacklist:

# FILTER REQUEST METHODS
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>

I am assuming, like John Hoff, that this has me covered. Am I correct?
Jeff Starr 2009/09/08 8:09 am • Post Author

Hi John, yep the 4G Blacklist includes these directives, so you’re covered. Thanks for the tweet :)

Hi Jordan, yes you are good to go. The reason for this article was to help those who may not have the 4G installed.
Thomas Scholz 2009/09/08 10:14 am

Jordan, remove HEAD from your list. This is a Good Thing.

Let’s say, someone checks the links on his website to find and remove outdated URLs: His script will use HEAD to verify that the linked pages are still there. If your response code isn’t 200 the link will probably be removed.

Forbidding HEAD means forbidding links from well maintained web sites.
Jordan Ogren 2009/09/08 11:54 am

@Jeff and @Thomas,

Thanks guys, I really appreciate your shared knowledge.
Jeff Starr 2009/09/08 11:50 am • Post Author

I may have to agree with Thomas here. The HEAD request method was blocked in the 4G Blacklist to help thwart referrer spam and other malicious exploits. At the time, there seemed to be no benefits to keeping the HEAD method, so it was blocked.

With Thomas’ hypothetical link-checking scenario, there may be reason to permit HEAD requests after all. This was something that I hadn’t thought of, but it certainly seems like a valid scenario. I will probably remove the HEAD block from the next, 5G Blacklist.

In this case, I think the pros of allowing outweigh the pros of blocking.
Greg 2009/09/08 3:13 pm

Pretty agree with Thomas too, for the HEAD.
But HEAD can also help to find the server version, if the owner set the server signature off.
Nan 2009/09/27 7:51 am

Hi Jeff! I would like to add this to my htaccess:

# FILTER REQUEST METHODS

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]

But I have already:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Can I have 2 or 3 different in the same htaccess?

Also, you say to put: RewriteRule .* - [F] and Jordan put: RewriteRule ^(.*)$ - [F,L] So what does the L stand for? Should I put it or not?

Thank you so much for your tips!!
Jeff Starr 2009/10/06 10:14 am • Post Author

Hi Nan, you can definitely add multiple blocks of HTAccess code into the same .htaccess file. It should work perfectly fine.

For the [L] flag, it simply means that the rule is the “Last” rule for that particular set of directives. This is one way of keeping the different rulesets separate and distinct from one another.

So yes, if you have multiple sets of rules, as in your case, you would want to include the [L] flag to keep everything distinct.

I hope this helps!
Abraham 2010/09/04 4:58 am

Limiting the allowed HTTP methods is great, but I think a whitelist approach is better :

RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET|POST)$ [NC]
RewriteRule .* - [F,L]

If a developer then specifically requires another method in his program (eg. PUT), deliberate action is required to enable it, which he should only take if he understands the need and implications.
Abraham 2010/09/07 12:19 pm

I ran some tests on (the servers of) my preferred hosting provider, and discovered that the TRACE method still isn’t being disabled, even though a whitelist approach disables everything else (except the whitelisted methods of course)!!

I’ve contacted them about it but thought I’d leave a comment here just to remind everyone to test (any and all) code once it’s in place, to make sure the code does what it’s supposed to!

Hope it helps someone.

« Previous Comments • 123 • Newer Comments »