TRACE
Diagnosing how intermediaries modify requests along the path to a server is the purpose of the HTTP TRACE method. The final recipient reflects the received request back as the response body, revealing changes made by proxies and gateways.
Usage
A TRACE request is a diagnostic tool for
inspecting the request chain between a client and
the origin server. The server responds
with 200 and includes the received request
message in the response body. One recognized format
is Content-Type message/http.
The response body contains a copy of the request
message as received, excluding fields the server
considers sensitive, allowing comparison with
the original request.
Properties
| Property | Value |
|---|---|
| Safe | Yes |
| Idempotent | Yes |
| Cacheable | No |
TRACE requests carry no body. Clients are responsible for not including sensitive fields such as credentials or Cookies in TRACE requests, since the echoed response exposes all received headers.
Microsoft IIS historically supported TRACK as a proprietary alias for TRACE. Both are subject to the same XST vulnerability and both need to be disabled in production.
Intermediary detection
When a request passes through proxies or gateways, each intermediary appends a Via header entry recording the protocol version of the upstream sender the message arrived from. Comparing the original request with the echoed copy reveals headers added, modified, or removed by each hop.
The Max-Forwards header limits how far a TRACE request travels. Setting this value to zero causes the first proxy to respond, which is useful for isolating a specific intermediary in a multi-hop chain. Decrementing the counter at each hop prevents infinite forwarding loops.
Security and XST
Cross-Site Tracing (XST) is an attack vector exploiting TRACE to capture HTTP headers, including Authentication tokens and cookie values. A malicious script sends a TRACE request to the target server, and the echoed response exposes headers not otherwise accessible to the script.
Note
Most production servers disable TRACE to prevent
XST attacks. Apache enables TRACE by default and
requires an explicit TraceEnable Off directive,
while nginx does not implement TRACE at all.
Browsers also block TRACE. The WHATWG Fetch
Standard lists TRACE as
a forbidden method, preventing JavaScript from
issuing TRACE requests. Disabling TRACE on the
server remains a recommended hardening measure
for all internet-facing servers.
Example
A TRACE request to the root resource. The server echoes the original request in the response body and includes a Via header showing the request passed through two proxy servers.
Request
TRACE / HTTP/1.1
Host: www.example.re
Response
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 91
Via: 1.1 proxy1.example.re, 1.1 proxy2.example.re
TRACE / HTTP/1.1
Host: www.example.re
Via: 1.1 proxy1.example.re, 1.1 proxy2.example.re
The Via header lists proxy1.example.re and
proxy2.example.re as intermediaries. Both
received the request over HTTP/1.1.
Each intermediary must append a Via entry
to forwarded requests, so the echoed body includes
the accumulated Via field added by the two proxies.
CORS
TRACE is a forbidden method in the WHATWG
Fetch Standard. Browsers block all attempts to
send TRACE through browser APIs such as fetch()
and XMLHttpRequest, for same-origin requests and
cross-origin CORS requests alike.
Disabling TRACE
Apache ships with TRACE enabled and disables it
with TraceEnable Off in the server
configuration. nginx does not implement TRACE, so
no action is needed. IIS requires removing TRACE
(and TRACK) from the allowed verbs in Request
Filtering. Caddy does not support TRACE by
default.
OWASP recommends disabling TRACE on all production servers. Security scanners flag enabled TRACE as a vulnerability even though modern browsers block TRACE requests via the Fetch Standard, which lists TRACE as a forbidden method. Apache documentation states enabling TRACE exposes no security vulnerability in httpd itself, so the hardening value lies in cutting off the XST attack path rather than patching a server flaw.
Disabling TRACE at the server level remains the primary defense against XST because non-browser HTTP clients and scripts are not bound by the Fetch Standard restrictions.
