Cross Site Tracing is a web attack that abuses the HTTP TRACE method to reflect request data, including cookies or headers, back to the client. If enabled, it can assist cross-site scripting or session theft. Defenders disable TRACE on web servers, verify allowed methods, and check that intermediaries do not pass it through.
How Cross Site Tracing Works
Cross Site Tracing is a method-based web attack. It depends on a server accepting TRACE and then echoing back request details that were supposed to stay inside the browser-to-server exchange. That behaviour turns ordinary headers into reflected data that can be harvested by script running in a page context.
The key issue is not the verb itself, but the unsafe reflection it creates. If a browser or intermediary allows untrusted content to trigger TRACE requests against a target origin, sensitive request material can become visible to an attacker-controlled page. The classic abuse path is to combine that reflection with another client-side weakness so the returned data can be read or reused.
Why TRACE Reflection Is Dangerous
TRACE is dangerous when it exposes cookies, authorization headers, or other request metadata that should remain opaque to client-side code. Even when the response body looks harmless, it can become a source of session material, routing information, or header content that helps an attacker move from information disclosure into account or session compromise.
It is especially problematic when systems sit behind reverse proxies, load balancers, or security gateways that do not handle HTTP methods consistently. A server may be hardened, yet an intermediary may still forward TRACE, creating an unexpected path for reflection and weakening the assumption that disallowed methods stay blocked end to end.
How Organisations Check Exposure
Exposure review starts with confirming whether any internet-facing web server, application gateway, or intermediary accepts TRACE at all. Security teams should test the full request path, not just the origin server, because method handling can differ across layers and products.
It also helps to review vendor documentation and hardening guidance for each web platform in use, then verify the result with live requests and configuration checks. A method may be disabled in one component but still permitted elsewhere, so the effective security posture is only as strong as the weakest hop in the chain. For broader web application attack patterns and method abuse, see Web Application Attacks Guide.
Remediation, Detection, and Recovery
The primary remediation is to disable TRACE wherever it is not explicitly required and to ensure upstream and downstream components reject it consistently. Where immediate removal is not possible, compensating controls should block method tampering, restrict who can reach the service, and reduce the chance that reflected headers contain reusable secrets.
Detection should look for TRACE requests in web logs, proxy logs, and edge telemetry, especially if they come from unusual origins or appear alongside other client-side attack activity. After suspected exploitation, review session validity, confirm whether cookies or bearer tokens were exposed, and investigate whether a cross-site scripting path or other browser-side weakness was used to read the response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | TRACE handling is part of web service method exposure and response behaviour. |
| V16 — Security Logging and Error Handling | TRACE attempts and anomalous method use belong in application logging and monitoring. | |
| Recommendation — Restrict allowed HTTP methods and verify the web service never reflects sensitive request data. Log and review unexpected HTTP methods, including TRACE, in web and proxy telemetry. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure web application configuration includes disabling dangerous HTTP methods and hardening request handling. |
| Recommendation — Harden web applications and servers so unsafe methods like TRACE are disabled everywhere they are exposed. | ||
Practitioner Guidance
Why practitioners should care: Cross Site Tracing is often missed because it sounds like a harmless diagnostic method, yet it can turn request echoing into a session-disclosure problem. Treat method allow-lists as security controls, not just protocol preferences.
Common misunderstanding: Disabling TRACE on the origin server is not enough if a proxy, CDN, or middleware layer still passes the method through. The practical question is whether the entire request path rejects it.
Practitioner takeaway: Verify method handling at every entry point and keep secrets out of headers that could be reflected back to a browser.
Related resources from NHI Mgmt Group
- What breaks when refresh tokens can be read from cross-site browser requests?
- How can untrusted notebook or Markdown content lead to cross site scripting in repository viewers?
- How should security teams reduce the impact of cross-site scripting in retail web applications?
- Who is accountable for tracing cross-chain laundering after a major crypto drain, and what skills do teams need?