對 API Payload 加密的理由, 並不是防止發生在兩端點環境內的資料竊取, 他是在防止中間人竊聽....

有人會問: 可是已經有 HTTPS 了, 怎麼還會有中間人竊聽?

請去看看市面上的 NGFW (次世代防火牆) 他們幾乎都能解開你的 HTTPS 取得明碼內容, 然後交給 Deep Inspector 模組分析 Payload, 判斷是否要採取攔阻行動? 網頁的 HTTPS 很容易解, 只需要插進一個可以被 Client 端信任的憑證就可以了, NGFW 就是塞了這樣一張憑證進去解開的..

如果你自己額外對 API 做了 Payload 加密的話, 中間人解開 HTTPS 之後, 還要再面對你的加密演算法, 這個對大部分只能做 HTTPS 竊聽的工具來說, 在沒有人工特別涉入調校之下, 幾乎是無法自行猜測演算法而去解開的...

當然, 如果中間人以人工進行二次解密的話, 還是有可能被解開; 但是這樣的機率極低, 已經比: 只使用自動化工具來竊聽來得更安全多了....

資安防禦是根據瑞士乳略理論, 經由層層疊加起來的防護, 來降低整體被突破的機率, 所以疊加多層防護, 肯定會有加分效果, 只是你要去評估那個投入的成本, 以及獲得的效益之間, 是否值得這樣做?

前端做加密比較沒有意義，畢竟都是看的到。
但還是看過2次請求法來達到前端加密的效果。

也就是第一次先送資料到後端做加密處理。
再將加密回傳的字串。往實際的請求送。

另一種方式則是CSRF傳送處理。這是比較簡單且常用的防外部送入的手法。

如果是非對稱加密的話 jwt 的簽名有個模式會用到

至於對稱加密，如果主機是跟別人租的話有可能會用到
Secret key 由使用者輸入的密碼產生
後端會直接儲存加密的資料
不過因為後端不知道 key 無法知道裡面有什麼
所以無法提供搜尋或讓其它使用者觀看
只適用於個人資料儲存的服務
(有點類似使用者上傳加密的壓縮檔）