如何保障Rest API的安全性

如何保障REST API的安全性，是一個不可迴避的話題。Open Web Application Security Project 給出了很多工程上的最佳實踐。

使用Https

最安全的做法就是，對你的所有的公開的API服務都強制使用HTTPS。

使用CORS

避免cross domain攻擊

認證Authentication

認證Authentication有多種方法，一般在工程中使用的有以下三種：

1。 Basic

這個是最經典的方法，在http的Authorization中放入使用者名稱+密碼，傳送給API，API拿到使用者名稱+密碼後，進一步驗證是否匹配，如果匹配，進一步處理請求，不匹配，直接返回403。

2。 JWT

JWT近幾年越來越流行，已經開始作為很多api服務的首選。JWT是JSON Web Token的簡稱，其本質就是一段JSON資料而已，當然，它有自己的業界標準格式RFC7519：

JWT例子，JWT分為header，payload，signature三部分

JWT的認證思路是：首先通訊雙方（比如IdP和API）必須提前約定一個secret，這個secret用來

驗證這個token的真偽（

注意這裡的secret不是來解密JWT，而是僅僅驗證，因為這個JWT資料不是加密的，在上圖中的左邊，它看起來像一段加密後的字元，但只是透過base64編碼的

）

。因為JWT的本質是一段JSON資料而已，任何人都可以隨意填寫其中的資料，比如username之類的，但是由於只有通訊的雙方知道secret，那麼也只有通訊的雙方可以正確的驗證傳送過來的JWT是不是真的，亦或是偽造的。

具體的在REST API中的應用流程大致就是：

首先，有一個專門的Identity Provider Service來給每一個客戶端發放JWT，REST API Service和Identity Provider Service事先要約定一個secret用來驗證JWT。

客戶端每次請求，首先先向Identity Provider Service發出請求，比如給其使用者名稱密碼，或者用微博賬戶來登入，如果Identity Provider Service確認客戶端的資訊是正確的，那麼返回其一個JWT。

客戶端使用該JWT傳送請求（一般放在http header中）給REST API服務，REST API使用事先約定好的secret來驗證此JWT，如果驗證透過，說明此JWT是由自己的Identity Provider Service發放給客戶端的，而非客戶端自己隨意製造的一個JWT。否則返回403。

REST API服務會使用secret來解碼JWT，獲取有用的資訊，比如使用者名稱，許可權等等，來進一步的授權Authorization。

上面提到的Identity Provider Service，自己可以開發，或者使用第三方的服務（比如Auth0）。多說一句，使用JWT做認證時，很多人會直接把許可權的資訊（比如ROLE_ADMIN）也寫入到JWT的payload中，這樣做沒錯，但是不推薦。因為ROLE_ADMIN之類的資訊也算敏感資訊，還有就是會暴露裡後端系統的user role的管理方式。最安全的方法：在JWT中放入儘可能少的許可權資訊，一個使用者id足矣。API後端要自己儲存使用者id所對應的許可權資訊。

3。 API Keys

API Keys的認證思路也很簡單，事先REST API服務會給客戶傳送一個隨機的唯一的字串作為API Key，並記錄在自己的資料庫裡。並且一般情況下，這個全域性唯一的API Key，代表了這個客戶的許可權資訊。

具體的在REST API中的應用流程大致就是：

客戶要使用我的API，我跟客戶商量好價格，許可權後，傳送一個API Key給客戶，並在自己的資料庫中存入這個API Key，並附帶其許可權資訊

客戶端使用API Key（一般放在http header中）向API傳送請求，API檢視這個API Key是否已經存在，如果不存在，返回403

如果API Key是有效的，那麼根據其對應的許可權資訊，做進一步的authorization。

對資料做驗證validation

在REST API中，POST，PUT方法會發送資料給後端，一定要對客戶端傳送的資料做驗證，這是保障後端的business logic能順利進行的有力保障。如有必要，一定要單獨的做一個validation layer。我看過太多的程式碼，裡面雜糅著資料驗證，異常處理，資料庫寫入。

後記

基本上我接過手的REST API都會遵循這些安全建議，以前的單體架構monolithic應用，會把認證和授權等多個步驟都放在一塊，導致不同的API開發組會不斷複製貼上這些程式碼。後來經過重構，把認證授權校驗邏輯打包成庫，但由於不同的組使用不同的語言，意味著庫也得用不同的語言開發多次，還是費力。現在隨著微服務的興起，API Gateway的使用，可以很大程度上緩解我所提及的情況，API Gateway作為整個後端系統的使用者認證的唯一接入點，提供一個統一的安全驗證服務，所有的REST API服務都部署於API Gateway之後，API Gateway會把每個請求中附帶加入一個通用的user token，每個REST API只需要解讀user token的內容，來具體處理使用者授權邏輯。