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 listing the protocol version used for forwarding. 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. Web servers such as Apache and Nginx disable TRACE by default. 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
forwarded the request using 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 CORS forbidden method.
Browsers block all attempts to send TRACE through
browser APIs such as fetch() and
XMLHttpRequest.
Disabling TRACE
Apache disables TRACE with TraceEnable Off in
the server configuration. nginx does not support
TRACE by default, 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.
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.