我目前的任務是開發股票市場數據 API，安全性是重中之重。我能夠使用 JWT、API 密鑰、中間件身份驗證來保護傳入的 GET 請求。假設當用戶未登錄時，眾所周知，所有 http 方法（尤其是 GET）都會以 http 狀態 401 未經授權的訪問進行響應。我的問題是，當用戶登錄我們的應用程序時，現在可以成功查詢 API 請求（服務器到服務器），但是當我將請求鏈接復制到瀏覽器新選項卡（例如 chrome）時，我可以看到回復。這是預期的，因為用戶已登錄，但我希望請求響應不會在瀏覽器中看到。我們的其他競爭對手使用 POST 來對抗瀏覽器默認的 GET。我們應該轉向 POST 嗎？我很掙扎，因為 GET 是請求內容的正確 http 方法。
2 回答
www說
TA貢獻1775條經驗 獲得超8個贊
對于像股票市場數據這樣的私人信息，我的第一選擇是發布請求。
我曾經通過檢測瀏覽器來阻止來自瀏覽器的 GET API 請求，基于用戶代理字符串和自定義頭元數據等內容，但根據經驗，這不是一個完美的解決方案。
我過去使用的另一個技巧是使用簡單的加密算法（它不安全但速度快。這只是一種干擾）來加密值。因此，如果有人確實提取了 json 響應，則數據將是垃圾，除非使用密鑰解密，在您的情況下，密鑰可能是 jwt 令牌。
再說一遍，這些技巧對高技術人員的安全沒有任何作用，但足以分散常規到平均逆向工程技巧的注意力。另外免責聲明，我從未使用 GET 來獲取任何重要的財務和股票相關信息。我的規則是 GET 處理普通的填充內容，POST 處理重要的內容。
一只名叫tom的貓
TA貢獻1906條經驗 獲得超3個贊
POST如果您想隱藏瀏覽器窗口中的輸出，最好移至此。與 一樣GET，瀏覽器將始終直接顯示輸出。
但請注意，如果有人想查看 API 響應，他們仍然可以使用 JS 模擬 API 調用并在瀏覽器控制臺中查看響應，或者使用 Postman 等客戶端來獲取響應。如果他們有適當的令牌，他們總是可以檢查你的響應，沒有辦法繞過它。
我相信它在新選項卡中也能工作，因為用戶已登錄，并且 JWT 令牌以可從新選項卡訪問的方式存儲在 cookie / localstorage / 中。并且您的服務器也能夠訪問它。
如果您使用 JS 應用程序（可能是 React？）發送令牌，并調整您的服務器每次都通過請求標頭接受令牌，在這種情況下，僅打開該 url 將不再有效，因為它將在其中丟失令牌請求標頭。
- 2 回答
- 0 關注
- 167 瀏覽
添加回答
舉報
0/150
提交
取消