HTTP TRACE Method Enabled

The HTTP TRACE method is a debugging feature that echoes your request back to you (a loopback). It's commonly left enabled on default server configs, and while it's low severity today, scanners and auditors still flag it as an unnecessary method and a security-hardening gap.

What is HTTP TRACE Method Enabled?

TRACE is one of the HTTP methods defined alongside GET, POST, OPTIONS, and others. Its job is diagnostic: when a client sends a TRACE request, a server that supports it echoes the exact request it received — headers and all — straight back in the response body. This "loopback" lets you see what any proxies between you and the origin added or changed along the way.

The problem is that almost nobody needs TRACE in production, yet it ships enabled in several default server configurations (historically Apache httpd, and older application servers such as Tomcat). Nobody turned it on deliberately; it was simply never turned off. That combination — a rarely-used debug method left on by default — is exactly what an automated vulnerability scanner reports as a finding, mapped to OWASP A05: Security Misconfiguration.

Why it's a risk / how it's exploited

The historical concern is an attack called Cross-Site Tracing (XST). Because TRACE reflects the full request — including headers the browser attaches automatically — an attacker who could get a victim's browser to send a TRACE request could read headers that JavaScript is normally forbidden from touching, such as an HttpOnly session cookie or Authorization header. Combined with another flaw (typically an XSS foothold), XST was a way to exfiltrate credentials that HttpOnly was supposed to protect.

Here's the honest, current picture: modern browsers block TRACE requests issued from JavaScript (XMLHttpRequest/fetch reject the method), so the classic XST chain is largely mitigated on today's browsers. That's why TRACE enabled is rated low. It is not a critical live exploit.

What remains is real but modest:

• Information disclosure / hardening gap. Reflecting the raw request can echo internal headers added by upstream proxies or load balancers, and confirms the method surface an attacker can probe.
• Unnecessary attack surface. Leaving debug methods enabled is a misconfiguration in its own right and a recurring audit and compliance finding — the same class of issue as a directory listing vulnerability, another OWASP A05 default-config leftover.

Treat it as cleanup, not an emergency: worth closing, not worth panicking over.

How to detect it

Send a TRACE request and see whether the server plays it back. From the command line:

curl -X TRACE https://example.com -i

If the response is HTTP/1.1 200 OK and the body contains your own request lines echoed back (TRACE / HTTP/1.1, your Host: and other headers), TRACE is enabled — that's the finding. A hardened server instead returns 405 Method Not Allowed or 403 Forbidden and no echoed request. You can run the same check through an intercepting proxy to confirm what a browser-side request would see.

Checking one host by hand is quick, but TRACE often survives on a forgotten virtual host, an origin behind a CDN, or a legacy app server while the main site looks clean. A full website vulnerability scan probes the method surface across all your hosts and flags TRACE alongside the rest of your OWASP Top 10 exposure.

How to fix it

Disable TRACE at every layer that can answer it — origin web server, application server, and any load balancer or WAF in front.

Apache — turn it off globally in httpd.conf:

TraceEnable off

Reload with apachectl configtest && systemctl reload apache2 (or httpd).

nginx does not implement the TRACE method and returns 405 by default, so it's usually already safe. To be explicit, restrict the allowed methods inside the relevant location block:

location / {
    if ($request_method !~ ^(GET|HEAD|POST)$) {
        return 405;
    }
}

(Note that nginx's if inside location has known limitations — keep the condition this simple to avoid surprises.)

Application / edge tiers. Disable it wherever else a request can be answered: on Tomcat set the connector attribute allowTrace="false" (its default), and block or reject TRACE at your load balancer, CDN, or WAF. After the change, re-run the curl -X TRACE check above and confirm you now get 405 or 403.

FAQ

Is HTTP TRACE enabled a critical vulnerability? No. It's rated low. The classic Cross-Site Tracing attack it enabled is largely mitigated because modern browsers block TRACE from JavaScript. It remains a valid hardening and information-disclosure finding worth fixing, not an active critical exploit.

What's the difference between TRACE and OPTIONS? OPTIONS reports which methods a resource supports; TRACE echoes your request back for loopback debugging. Both are often left enabled by default. OPTIONS is usually needed (CORS preflight uses it), but TRACE almost never is, so disable TRACE specifically.

---

Not sure whether TRACE still answers on any of your hosts? Run a free website vulnerability scan to find enabled debug methods and other security misconfigurations across your attack surface.