HTTP GET 與 POST 傳輸機敏資料的安全迷思與 RESTful 設計抉擇

琳

我們公司的開發安全指引中說，「不應使用 HTTP GET 傳輸機敏資料」，並且「應使用 HTTP POST 方法」。 請你思考並解說這個規則是否正確。使用 POST 是否能帶來足夠的提升資安的效果，讓我應該放棄部份的 RESTful 設計並這麼做? 考量在確實是 GET 語境時，我是否會因為使用 GET 而非 POST 傳送機敏資料而曝露在風險之中?

Felo Search

開發安全指引中「不應使用 HTTP GET 傳輸機敏資料，應改用 POST」的規則，其核心精神是為了防止機敏資訊因 GET 的特性而暴露在 URL 中，這在方向上是正確的，但此規則本身是一個過於簡化的論述，可能導致開發者產生「POST 本身就是安全的」此一危險的誤解。

將資料擷取（GET 語境）的操作改用 POST 方法，雖然能避免資料出現在 URL、瀏覽器歷史紀錄與伺服器日誌中，從而降低了資料暴露的風險，但這並非真正的傳輸安全。在未使用 HTTPS 的情況下，無論是 GET 還是 POST，其傳輸的資料均為明文，可被輕易攔截¹²。真正的傳輸安全必須依賴 HTTPS 加密³⁴。

此外，為了這項有限的「隱私」提升而放棄 RESTful 設計原則，會帶來顯著的工程代價，包括：破壞 API 的語意化、喪失 GET 的冪等性（Idempotency）與可快取性（Cacheability），從而增加系統的複雜性與維護難度，並可能引發非預期的副作用⁵⁶。

因此，更精確且安全的實踐應是：

1. 強制使用 HTTPS：這是保障傳輸安全的根本，所有 API 端點都應使用 HTTPS⁷⁸。
2. 遵循 RESTful 原則：在 HTTPS 的基礎上，繼續使用語意化的 HTTP 方法（GET 用於讀取，POST 用於建立）⁹¹⁰。
3. 避免在 URL 中放置機敏資料：這是對原始規則的精煉。即使在 HTTPS 下，也應避免將密碼、Token 等高度敏感資訊置於 URL 參數中，以防其在伺服器日誌、瀏覽器歷史等環節中留下紀錄¹¹¹²。

結論是，不應盲目地將所有 GET 操作替換為 POST。應優先確保 HTTPS 的全面實施，然後在遵循 RESTful 設計的同時，審慎評估並最小化 URL 中參數的敏感性。

HTTP GET 與 POST 在資料傳輸上的根本差異

要理解其安全性議題，首先必須釐清 GET 與 POST 在 HTTP 協定中的設計與資料承載方式。這兩者最直觀的區別常被比喻為「明信片」與「信封」¹³¹⁴。

GET：明信片模型

GET 請求旨在從伺服器擷取資源¹⁵¹⁶。其所有參數都附加在 URL 的查詢字串（Query String）中，對外完全可見¹⁴。

• 範例： https://api.example.com/users?id=123
• 特性：
  • 可見性： 參數直接暴露在 URL 中，任何能看到 URL 的環節（如瀏覽器網址列、網路代理、伺服器日誌）都能看到參數內容¹⁷¹⁸¹⁹。
  • 長度限制： URL 長度受限於瀏覽器和伺服器，通常最大約為 2048 個字元¹³²⁰。
  • 可快取性： GET 請求的結果可以被瀏覽器或代理伺服器快取，以提升後續存取效能¹³¹⁶。
  • 冪等性（Idempotency）： 多次發送相同的 GET 請求，對伺服器資源狀態的影響應完全相同，即不會產生副作用⁵²¹。

POST：信封模型

POST 請求旨在向伺服器提交資料，通常用於建立新資源或觸發需要附帶資料的處理程序¹⁵²²²³。其參數被放置在請求的主體（Request Body）中，不會顯示在 URL 上²⁴¹⁴。

• 範例：

  POST /users HTTP/1.1
  Host: api.example.com
  Content-Type: application/json
  
  {"name": "Judy", "role": "admin"}
  

• 特性：

  • 隱蔽性： 參數位於請求主體內，不會出現在 URL 中，提供了表面的隱私¹³²⁵。
  • 無長度限制： 理論上可以傳輸大量資料¹³²⁶。
  • 不可快取性： POST 請求的結果預設不可被快取¹³²⁰。
  • 非冪等性： 多次發送相同的 POST 請求可能會建立多個資源，產生不同的結果⁵²⁷。

安全性分析：「POST 比 GET 安全」的迷思與真相

公司的安全指引根植於一個普遍的觀念：POST 比 GET 更安全。這個說法在特定情境下部分成立，但若不深入理解其前提與限制，將會產生嚴重的安全誤區。

GET 的風險：暴露而非洩漏

使用 GET 傳輸機敏資料的主要風險在於其可見性，而非傳輸過程本身的不安全。具體風險點包括：

1. URL 可見性與肩窺攻擊（Shoulder Surfing）： 使用者螢幕上的瀏覽器網址列會直接顯示包含機敏資料的 URL¹⁸。
2. 瀏覽器歷史紀錄： 包含參數的完整 URL 會被儲存在瀏覽器歷史紀錄中，任何能存取該電腦的人都可能看到¹³²⁸²⁹。
3. 伺服器與代理日誌（Server/Proxy Logs）： 網站伺服器、防火牆、負載平衡器等網路節點通常會記錄完整的請求 URL，這會導致機敏資料以明文形式儲存在日誌檔案中³⁰²⁸³¹。
4. 書籤與分享： 使用者可能會將包含機敏資料的 URL 加入書籤或不經意地分享給他人²⁸²⁰。
5. Referrer 標頭： 當使用者從一個包含機敏資料的頁面點擊連結到另一個網站時，完整的 URL 可能會透過 HTTP Referer 標頭傳送給目標網站。

這些風險的核心是資料在端點（客戶端、伺服器）的靜態儲存與暴露。

POST 的「安全」假象及其侷限性

將請求從 GET 改為 POST，確實可以有效規避上述所有風險，因為資料被移入了請求主體¹³¹⁴。然而，這僅僅是將資料從「明信片」變成了「未加密的信封」。

關鍵限制：HTTP 本質是明文傳輸

無論是 GET 還是 POST，只要是透過標準的 HTTP 協定傳輸，所有資料（包括 URL、標頭和主體）都是未加密的明文¹²³²。攻擊者若處於網路中間位置（Man-in-the-Middle），可以輕易地使用封包分析工具（如 Wireshark）攔截並讀取所有傳輸內容¹³³³⁴。

因此，在 HTTP 下，POST 與 GET 一樣不安全。認為 POST 能提供傳輸層級的安全性是一個極其危險的誤解。

真正的解決方案：HTTPS (HTTP over TLS)

傳輸安全的基石是 HTTPS。HTTPS 會在 HTTP 協定外層包裹一層 TLS/SSL 加密。這層加密保護了整個 HTTP 請求，包括：

• 請求行（包含 URL 和查詢參數）
• 請求標頭（Headers）
• 請求主體（Body）

當使用 HTTPS 時，即使是 GET 請求中的 URL 參數，在傳輸過程中也是被加密的，中間人無法窺視其內容³³⁵⁴。這從根本上解決了傳輸過程中的資料洩漏風險。

違背 RESTful 設計的工程代價

在已經實施 HTTPS 的前提下，若仍堅持將 GET 操作改為 POST，雖然能解決日誌記錄等端點暴露問題，但會引入一系列嚴重的軟體工程問題，這些代價往往超過其帶來的有限好處。

RESTful API 的核心理念是使用統一的介面（HTTP 方法）來操作定義清晰的資源（URL），以達到系統的鬆散耦合與平台獨立性³⁶³⁷。

破壞語意化與可讀性

RESTful 設計風格將 HTTP 方法對應到資料的 CRUD（建立、讀取、更新、刪除）操作⁹³⁸。

• GET: 讀取 (Read)
• POST: 建立 (Create)
• PUT/PATCH: 更新 (Update)
• DELETE: 刪除 (Delete)

這種對應關係使得 API 非常直觀且易於理解³⁹⁴⁰。當開發者看到一個 GET /api/users/123 的請求時，能立刻明白其意圖是「獲取 ID 為 123 的使用者資訊」。如果將其改為 POST /api/users/123，語意就變得模糊不清，是「建立」還是「獲取」？這會極大地增加開發者的溝通成本與學習曲線，違背了 RESTful 設計的初衷⁴¹⁴²。

喪失冪等性（Idempotency）

冪等性是指一個操作無論執行一次或多次，其結果都相同⁵²¹。GET、PUT、DELETE 都是冪等的，而 POST 不是⁵²⁷。

• GET /users/123：執行 100 次，你得到的都是同一個使用者的資料，伺服器狀態不變。
• POST /users：執行 100 次，你可能會建立 100 個新使用者。

將讀取操作用 POST 實現，會讓這個本應安全的讀取操作失去冪等性。這在網路不穩定、需要重試的場景下尤其危險。客戶端或代理在請求超時後自動重試一個 POST 請求，可能會引發非預期的後果。

喪失可快取性（Cacheability）

HTTP 協定允許瀏覽器和中間代理（如 CDN）快取 GET 請求的回應¹³¹⁶。這對於不常變動的資料能極大提升效能、降低伺服器負載。而 POST 請求的回應在預設情況下是不可被快取的¹³²⁰。將讀取操作改為 POST，等於放棄了整個 HTTP 快取機制帶來的效能優勢。

例外情況：何時可考慮用 POST 進行查詢

儘管應盡力避免，但在極少數情況下，使用 POST 進行資料查詢是可以接受的。最常見的場景是當查詢條件過於複雜或龐大，導致 GET 請求的 URL 長度超過了瀏覽器或伺服器的限制（約 2KB）⁴³。例如，一個需要傳入數百個 ID 進行批次查詢的 API，將這些 ID 放在 POST 的請求主體中是更務實的作法。

結論與最佳實踐建議

綜合以上分析，公司安全指引中的規則是一個善意但過於簡化的建議。直接遵循它可能會導致對安全性的錯誤認知，並犧牲掉 RESTful 設計帶來的工程優勢。

一個更成熟、更安全的 API 設計策略應遵循以下層次：

1. 第一道防線：強制使用 HTTPS
   這是最重要且不可妥協的基礎。確保所有 API 端點都透過 HTTPS 提供服務，從根本上保障資料在傳輸過程中的機密性與完整性⁷⁸⁴⁴。

2. 第二道防線：遵循 RESTful 語意化設計
   在 HTTPS 的保護下，應大膽地使用符合語意的 HTTP 方法。使用 GET 進行資料讀取，以利用其冪等性、可快取性和清晰的語意⁹¹⁰⁴⁵。

3. 第三道防線：精煉化 URL 參數管理
   這是對原始規則精神的正確詮釋。即使在 HTTPS 下，也應避免將高度機敏的資料（如密碼、Session Token、API 金鑰）直接放在 URL 參數中。這是為了防範端點暴露的風險，例如伺服器日誌未經處理、開發者不慎分享 URL 等¹¹¹²。

   • 可接受的 GET 參數： 非敏感的識別碼（如 UUID）、分頁參數（limit, offset）、篩選條件等³⁶⁷。
   • 應避免的 GET 參數： 密碼、個人身份證號、高權限的存取權杖。這些更適合透過 HTTP 標頭（如 Authorization）或在 POST/PUT 的請求主體中傳遞。

4. 伺服器端強化：日誌過濾與清理
   作為最後的補充，應在伺服器端實施日誌過濾機制，自動移除或遮蔽日誌中可能出現的敏感參數，確保即使發生配置錯誤，機敏資料也不會被永久記錄下來³¹。

總結來說，您不應該僅僅因為安全考量而放棄 RESTful 設計。正確的做法是建立一個多層次的防禦體系：以 HTTPS 為基礎，以 RESTful 為設計框架，以謹慎的參數管理為細節優化。這樣才能在確保安全的同時，兼顧系統的健壯性、可維護性與效能。