HTTP定義了一組請求方法，以表明要對給定資源執行的操作。指示針對給定資源要執行的期望動作。 雖然他們也可以是名詞, 但這些請求方法有時被稱為HTTP動詞. 每一個請求方法都實現了不同的語義。其中，TRACE方法沿着到目標資源的路徑執行一個消息環回測試。
關於TRACE方法
客戶端發起一個請求時，這個請求可能要穿過防火牆、代理、網關或其他一些應用程序。每個中間節點都可能會修改原始的 HTTP 請求。TRACE 方法允許客戶端在 最終將請求發送給服務器時，看看它變成了什么樣子。
TRACE 請求會在目的服務器端發起一個 環回 診斷。行程最后一站的服務器會彈回一條 TRACE 響應，並在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看在所有中間 HTTP 應用程序組成的請求 / 響應鏈上，原始報文是否，以及如何被毀壞或修改過。
TRACE方法主要用於診斷。也就是說，用於驗證請求是否如願穿過了請求 / 響應鏈。它也是一種很好的工具，可以用來查看代理和其他應用程序對用戶請求所產生效果。
盡管TRACE可以很方便地用於診斷，但它確實也有缺點，它假定中間應用程序對各種不同類型請求(不同的方法——GET、HEAD、POST 等)的處理是相同的。很多HTTP應用程序會根據方法的不同做出不同的事情——比如，代理可能會將POST請求直接發送給服務器，而將GET請求發送給另一個HTTP應用程序(比如Web緩存)。TRACE並不提供區分這些方法的機制。通常，中間應用程序會自行決定對TRACE請求的處理方式。
TRACE 請求中不能帶有實體的主體部分。TRACE響應的實體主體部分包含了響應服務器收到的請求的精確副本。當TRACE請求到達目的服務器時， 整條請求報文都會被封裝在一條HTTP響應的主體中回送給發送端。當TRACE響應到達時，客戶端可以檢查服務器收到的確切報文，以及它所經過的代理列表(在 Via 首部)。TRACE 響應的 Content-Type 為 message/http，狀態為 200 OK。
關於跨站跟蹤攻擊（CST/XST）
CST攻擊是一種使用XSS和HTTP TRACE功能來進行攻擊的方式。它是一種攻擊技巧，可以利用它避開HttpOnly對cookie提供的保護，使之能夠通過客戶端JavaScript獲取已經標記為HttpOnly的cookie值。
正常情況下，客戶端腳本（如JS腳本）是可以通過document.cookie函數獲得，這樣如果有XSS跨站漏洞，cookie很容易被盜取。瀏覽器有一個安全策略，通過設置cookie的httponly屬性，這樣客戶端腳本就不能通過document.cookie訪問該cookie，即時有跨站漏洞，也不能盜取用戶cookie。（注意：httponly屬性對正常的HTTP請求並沒有影響，即時Cookie設置了HTTPONLY屬性，當用戶瀏覽有效域中的站點時候，這個Cookie仍然被自動發送，只是不能使用腳本來訪問該Cookie。(解釋HTTPONLY）
一般客戶端向服務器請求是利用HTTP GET和POST方式，但那只是常見，還有其它方式（詳細參考RFC2616文檔）。其中HTTP TRACE也是一種方式，這種向服務端請求信息主要用於調試web服務器連接用。如果請求有效，則在響應中會在實體中包含整個請求消息。（解釋HTTP TRACE）
測試用例
某應用程序服務端啟用了TRACE方法，先看原始請求/響應數據，如下圖所示：
響應主體中攜帶它收到的原始請求報文：
原始響應下會下載一個未知格式的文件。因此此例中需要除了需要在請求頭中構造惡意腳本以外，同時篡改客戶端解析類型和方式，將響應中的Content-Type:message/http，改為Content-Type:text/html，如下圖：
從而使得客戶端成功執行構造的腳本：
CST與XSS的聯系和區別：
聯系：CST是XSS的一種子類，也屬於XSS跨站漏洞。
區別：瀏覽器請求的方式不一樣，普通的XSS一般通過GET和POST方式在頁面上輸入攻擊腳本實現，但是CST如果要在頁面上輸入，需要找到會通過TRACE發送的輸入點，一般是自己構造攻擊報文在TRACE方法中進行發送。
測試相關：
由於普通的XSS攻擊報文可以通過GET或者POST被提交，而CST則要通過TRACE來提交，由於比較少用，目前還未搜索到有頁面輸入框可以使用TRACE提交的。因此對它的測試需要注意，攻擊腳本中需要自己提供發送函數，比如使用XMLHttpRequest發送請求（當然普通的XSS攻擊也需要覆蓋用XMLHTTPRequest發送GET、POST請求）。
測試總結：對CST的測試只需要將普通XSS的攻擊特征腳本放在HTTP的TRACE位置發送出去即可。