保護用Play Framework開發的REST API

我目前正在使用Play Framework 2.3開發REST/JSON API。我目前正在考慮一種有效而簡單的方法來保護API。就安全而言，我的意思是有些行動需要最終用戶進行認證才能被接受。保護用Play Framework開發的REST API

目前，我依賴於Play Framework會話管理（作爲提醒，它將所有會話數據存儲在每個查詢中發送的簽名cookie中 - 因此，它是無狀態的，即使cookie可以被客戶讀取，它不能被更新）。

流程很簡單：

最終用戶登錄感謝API客戶端
如果被接受，一個cookie在應答集
當發送下一個查詢發送登錄查詢，API客戶端會自動添加cookie，因此最終用戶被API識別。

我的問題如下：我是否真的需要進一步提高安全性？我無法找到這個現有的機制不能正常工作的原因...

在此先感謝！ PS：目前我既是API的開發者和消費者，也沒有公開發布的計劃。

PPS：我正在開發的客戶端使用AngularJS

來源

2015-10-19 Nicolas B.

我不明白這個問題，因爲「進一步」是非常廣泛的。爲什麼你對自己施加進一步的安全限制，知道你是唯一的消費者？你關心什麼 - 只是一般的安全最佳實踐，框架安全性的完整性還是其他？ – Chrizt0f

誠如我所說，API並非公開。在這種情況下，這只是爲了確保我不會忘記可能導致安全漏洞的一件大事（所以最好的做法是）。但說實話，我的問題也適用於其他使用公共API的案例。 –

看看這篇文章，它解釋了在遊戲環境中的跨站點請求僞造[18076206]（http://stackoverflow.com/questions/18076206/how-do-i-secure-my-rest-api-developed-in- playframework？rq = 1）和播放自己的[文檔]（https://www.playframework.com/documentation/2.4.x/ScalaCsrf）在這個問題上 – Chrizt0f

你並不需要一個簡單的Web應用程序。這是正確的解決方案。

您可以認爲只有在可用性方面才能使用令牌。

當然我假設你使用https。

來源

2015-10-19 19:24:48

是的，它是基於HTTPs。 –

所以我沒有看到使用令牌（JWT）的任何安全原因。不同的方面 - 是的，令牌更「休閒」，更靈活。還有一件關於cookie的文章 - 其他標題甚至有點安全，但只有一點 - 例如「HTTPOnly」和「Secure」等。 –

而不是在Cookie中設置值，您可以嘗試使用Http標頭x-auth-token。儘管這不是一個遵循的規則，但它是基於Token的身份驗證的標準 – Sivailango

保護用Play Framework開發的REST API

回答

相關問題