Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I saw many posts here on this site dishing out advice on disabling HTTP TRACE method to prevent cross site tracing. I sought to do the same thing. But when I read the Apache documentation, it gives the opposite advice:


Despite claims to the contrary, TRACE is not a security vulnerability and there is no viable reason for it to be disabled. Doing so necessarily makes your server non-compliant.

Which should I follow?

share|improve this question
Interestingly Apache's comment here is incorrect: the lack of TRACE does not make the server non-compliant. TRACE is marked a "SHOULD" in RFC-2616 and can therefore be ignored if there is good reason and low practical impact. – couling Jun 14 at 15:12
up vote 18 down vote accepted

One of the wisest security principles says that what is unused should be disabled.

So the first questions is: Are you really going to use it? Do you need it to be enabled?

If you are not going to use TRACE method then in my opinion it should be switched off. It will prevent your app not only against XST, but also against undiscovered vulnerabilities related to this channel, which can be found in the future.

share|improve this answer

In order to send a TRACE command to a given server, you must have the right to do so, which is normally prevented by the Same-Origin Policy (the famous "SOP"). If a piece of malicious JavaScript, intent on stealing your cookie on site, is able to send a TRACE request to, then that evil JavaScript has already won and you are in deeper trouble. Disabling TRACE does not solve the real problem (and that problem is client-side).

To make an outrageous analogy: there are people who murder others by stabbing them with knives. Would banning knives really solve the issue? (I'm using knives and not guns here, because it is pretty obvious that knives are very useful tools for tasks other than murdering people, e.g. I use knives daily for cooking; the same cannot be said about guns. Similarly, the HTTP TRACE method is a useful debugging tool.)

share|improve this answer
Most (all?) browsers prevent TRACE from working in javascript, so there's that. Doesn't prevent a java/flash app from doing it though. – Nathan C Apr 30 '14 at 14:59
@NathanC But if someone's running a Java / Flash app in their browser, they have bigger problems. – Parthian Shot Jul 25 '15 at 20:16

Which should I follow?

You're going to be scanning your website, what... Annually? Quarterly? Monthly, weekly? And that'll show up on all those scans. Until you tell your scanner to skip that check, or to make an exception... at which point it'll sit there until you have a third party run a scan for you, or one of your partners scans your site and puts it under your nose as "How can you leave such a basic checklist item unaddressed?

Conversely, you're going to be scanned for compliance to the HTTP spec... never. You'll need to actually use TRACE... pretty much never. The practical effect on interoperability with your clients will be... nada.

I understand and agree with @Tom-Leek's point that it's not much of a security issue. However, I disagree in that the downside of disabling is miniscule, and the upside of disabling it is to avoid a lot of annoyance that would otherwise end up in your lap.

I'm not the only one to think that way - which is why Apache added a directive in 1.3.34 and 2.0.55 to simply shut TRACE off:

TraceEnable Off

Here's a good page discussing it, including manual test steps.

share|improve this answer
Wow, according to Apachehaus (not sure if it's trustworthy), those 2 versions of Apache were released in 2005! – trysis Apr 30 '14 at 15:26
+1 for pointing out that we are often defending against auditors, CISSPs, and other earnest security folks questioning our decisions later. This is why I often use the phrase "still vulnerable to CISSP attacks" in my security reports. – mcgyver5 Apr 30 '14 at 16:00
I'd like to add a very gentle word of warning about second guessing security recommendations. Hacks can be painfully obscure. Just because you can't exploit a vulnerability doesn't mean a hacker can't. To that end, keeping the auditors happy can be a useful security exercise even when it looks meaningless. – couling Jun 14 at 15:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.