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?

  • 2
    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. Commented Jun 14, 2016 at 15:12

3 Answers 3


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.

  • 9
    This doesn't answer the question asked. What if you are using it or planning to use it?
    – Pacerier
    Commented Nov 10, 2016 at 17:59
  • I believe the question was about a current state of art back then. And it seems that OP was satisfied with the answer. Commented Nov 14, 2016 at 15:25

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 example.com, is able to send a TRACE request to example.com, 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.)

  • 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
    Commented Apr 30, 2014 at 14:59
  • @NathanC But if someone's running a Java / Flash app in their browser, they have bigger problems. Commented Jul 25, 2015 at 20:16
  • 1
    @TomLeek, Your answer asserts that TRACE is safe because attacks are already prevented by SOP and SOP alone. This is a halfhearted and narrow-minded way of analyzing security. Fact is, regardless of SOP status, malicious TRACE can still be sent to servers by using SSL renegotiation attacks. And what about in the future? The secure viewpoint should be that there is Every Reason to disable TRACE because its such a tasty vector of abuse. It's like playing russian roulette with blank cartridges. Just don't.
    – Pacerier
    Commented Nov 10, 2016 at 18:58
  • [cont] Re "Similarly, the HTTP TRACE method is a useful debugging tool", what would be the other use cases of playing russian roulette with an actual server and are there no safer alternative methods? TRACE is actually closer in analogy to a Katana than a typical small kitchen knife.
    – Pacerier
    Commented Nov 10, 2016 at 19:02

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.

  • Wow, according to Apachehaus (not sure if it's trustworthy), those 2 versions of Apache were released in 2005!
    – trysis
    Commented Apr 30, 2014 at 15:26
  • 7
    +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
    Commented Apr 30, 2014 at 16:00
  • 1
    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. Commented Jun 14, 2016 at 15:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .