伺服器端的 log 將明文記下完整 url；瀏覽器上的訪問歷史也會明文記下完整 url；Referrer headers 裡也忠實記下完整 url，然後在別人家的 Google Analytics 上顯示。
我們經常聽到的一個常見問題是：“URL 中的引數是否可以安全地傳遞到安全網站？”這個問題常常出現在客戶看了 HttpWatch 捕獲的 HTTPS 請求後，想知道還有誰可以看到這些資料。
例如，假設在一個查詢中，使用如下安全的 URL 傳遞密碼字串：
https://www.httpwatch.com/?password=mypassword
HttpWatch 能夠顯示安全請求的內容，因為它與瀏覽器整合，因此它能夠在 HTTPS 請求的 SSL 連線對資料加密之前檢視資料。
如果你使用網路嗅探器檢視，例如 Network Monitor，對於同一個請求，你只能夠查閱加密之後的資料。在資料包跟蹤中沒有可見的網址，標題或內容：
您可以信任 HTTPS 請求是安全的，只要：
- 未忽略任何SSL證照警告
- Web 伺服器用於啟動 SSL 連線的私鑰在 Web 伺服器本身之外不可用。
因此，在網路層面，URL 引數是安全的，但是還有一些其他基於 URL 洩漏資料的方法：
URL儲存在 Web 伺服器日誌中–通常每個請求的完整URL都被存放在伺服器日誌中。這意味著URL中的任何敏感資料（例如密碼）會以明文形式儲存在伺服器上。以下是使用查詢字串通過HTTPS傳送密碼時儲存在httpwatch.com伺服器日誌中的條目： **2009-02-20 10:18:27 W3SVC4326 WWW 208.101.31.210 GET /Default.htm password=mypassword 443 … 通常認為即使是在伺服器上，儲存明文密碼從來都不是好想法 2.URLs are stored in the browser history – browsers save URL parameters in their history even if the secure pages themselves are not cached. Here’s the IE history displaying the URL parameter:URL儲存在瀏覽器歷史記錄中–即使安全網頁本身未快取，瀏覽器也會將URL引數儲存在其歷史記錄中。以下是IE的歷史記錄，顯示了URL的請求引數：
如果使用者建立書籤，查詢字串引數也將被儲存。
URL在Referrer請求頭中被傳遞–如果一個安全網頁使用資源，例如javascript，圖片或者分析服務，URL將通過Referrer請求頭傳遞到每一個嵌入物件。有時，查詢字串引數可能被傳遞並存放在第三方站點。在HttpWatch中，你可以看到我們的密碼字串正被髮送到Google Analytics：
結論
解決這個問題需要兩步：
- 只有在絕對必要的情況下傳遞敏感資料。一旦使用者被認證，最好使用具有有限生命週期的會話
ID來標識它們。
使用會話層級的 cookies 傳遞資訊的優點是：
- 它們不會儲存在瀏覽器歷史記錄中或磁碟上
- 它們通常不儲存在伺服器日誌中
- 它們不會傳遞到嵌入式資源，例如圖片或
JavaScript庫 - 它們僅適用於請求它們的域和路徑
以下是我們的線上商店中，用於識別使用者的 ASP.NET 會話 cookie 示例：
請注意，cookie 被限制在域 store.httpwatch.com，並且在瀏覽器會話結束時過期（即不會儲存到磁碟）。
你當然可以通過 HTTPS 傳遞查詢字串，但是不要在可能出現安全問題的場景下使用。例如，你可以安全的使用它們顯示部分數字或者型別，像 accountview 或者 printpage，但是不要使用它們傳遞密碼，信用卡號碼或者其他不應該公開的資訊。