穩定好用的認證系列API合輯
通常在 B 端產品中，會對某些 API 返回的部分字段數據進行脫敏，比如手機號，郵箱等，以保證用戶的信息隱私。
盡管 API 層面對敏感數據做了脫敏處理，但敏感數據如果未進行加密處理，或加密的強度不夠，或者沒有安全的存儲加密數據，以至于攻擊者仍然能夠獲得敏感信息，進而攻擊者可能利用此漏洞對客戶端，或服務器發送特殊構造的數據，發出攻擊，從而了解后臺數據庫表等信息，對系統安全構成威脅。這也就是接口敏感數據被竊取了。
注：某單位在某省攻防演練，一下扣到負幾千分的原因，您找到了嗎？需要防護改進，請聯系三沐，必須給你安排的明明白白。
深究起來，XSS 攻擊更多偏向于前端這一層，但是對于一個能夠提供充分安全保障的系統來說，API 的對于參數的安全校驗也是非常重要的一環，對于系統來說，應該確保核心 API 的業務對于所有的入參都應該是安全，可信且經過校驗之后才能進行數據存儲的。這樣可以從源頭上保障 XSS 攻擊影響的范圍進一步縮小。
在系統架構設計之初，系統安全一定是一個重要的考量因素被納入到架構設計規劃中，系統安全關乎著既關乎公司的生存，也關乎產品的盈利，更進一步說，更關乎著法律法規對公司的監管合規性依據。下圖所示，為一個通用的微服務業務架構圖。
從實踐經驗來看，安全在一個系統的架構設計中占據著舉足輕重的地位，從上圖來看，可以說，安全考慮在架構設計的每一環都有著落地的目標，拆開來看，具體如下所述。
涉及到前端安全的技術，比如：
· 頁面表單的防重提交（功能上限制防刷的可能性）；
· 接口請求前關鍵參數的校驗，脫敏，XSS 不安全字符的自動識別；
· 使用參數加密，Base64 處理，禁止明文傳輸;
防火墻本身具有較強的抗攻擊能力，它是提供信息安全服務、實現網絡和信息安全的基礎設施之一。
防火墻對于一個互聯網公司的重要意義毋庸置疑，尤其是金融類，銀行類等 B 端產品，防火墻的作用可以說是不可替代的，盡管這個技術已經不是什么新鮮的東西，但基本上所有的軟件公司在產品發布到線上環境之后，所有來自外部的請求，都會經過服務器廠商的防火墻，只有通過了防火墻這一層請求才能繼續往下進行。
關于防火墻的作用，這里簡單列舉如下：
·防止來自被保護區域外部的攻擊，保護易受攻擊的網絡服務資源和客戶資源；
·集中安全管理，通過集中的安全策略配置，以便統一管理和執行安全政策；
·防止信息外泄和屏蔽有害信息，執行安全檢查，嚴格控制進出網絡的數據，過濾和屏蔽有害信息，防止信息外泄；
·安全審計和告警，通過對網絡存取訪問進行監控審計，有效跟蹤各類網絡活動，及時發現問題和及時報警。
關于網關，基本上所有的人都多少有一定的了解，網關在一個安全的系統架構設計中的作用，可以說是承上啟下，至關重要，大體來說，從安全的角度來講，主要體現在如下幾個方面：
拿 nginx 來說，如果后端的接口真實地址是：/API/v2/user/get/1，為了確保接口安全，屏蔽真實的地址，通過nginx 的反向代理之后，接口可能變成這樣：/platform/biz/API/v2/user/get/1。
從系統安全和系統可用性的角度講，為了確保系統的高可用性，通常應用服務集群部署，這樣可以避免單節點壓力過大而造成業務高峰時系統不可用，有了網關這一層，就可以通過網關的配置動態實現負載均衡，以達到均衡流量的效果，從而對系統過載形成防護。
以 nginx 來說，提供了可編程式的配置，通過編寫腳本代碼，對經過 nginx 的請求進行監控，尤其是對于那些惡意刷接口的請求，可以很好的進行識別，甚至可以在 nginx 這一層對那些惡意請求的 IP，IP 段進行黑名單的設置，從而對后臺的服務進行第一層的安全防護。
對一個系統來說，可用性已然成了系統是否穩定的考量因素的重要標準，當業務高峰期時，不管是外部的惡意請求，還是類似搶單這樣的瞬間大流量來說，為了保障系統的整體可用性，必要的限流措施也是確保系統安全的重要手段，而網關作為承載系統流量的入口，在網關這一層做一定的限流管控是很有必要的。
在討論了架構設計中的安全防護措施后，作為系統對外提供數據來源的核心后臺服務的 API 接口，關于 API 的安全考慮，許多開發者在設計過程中尚未引起足夠的重視。以下是小編分享的一個有趣現象：在過去的工作經歷中，甲方公司在項目驗收時，通常會對整個源碼進行安全審計，其中 API 接口的安全問題，如 XSS 攻擊、CSRF 攻擊和接口被刷的風險，常常是審計中最容易出問題的部分。
接下來，我們將探討針對這些問題以及日常開發中API 安全的一些規范性要求。
在當前流行的微服務架構中，后臺 API 的訪問邊界必須規范：
針對大平臺，如 PaaS 平臺，其由多個內部服務組成，這些服務之間的調用（如 Dubbo 或 HTTP 調用）需要規范：
appName 這樣的標識進行認證。對于登錄、獲取用戶信息等接口，需加密處理以防會話劫持：
前端請求時，在 header 中添加 token 等參數，進行統一校驗。更高級的安全可以混合定制化參數。
即使有統一的防護措施，對核心業務 API 仍需額外防刷：
從安全角度，POST 請求比 GET 請求安全，建議當查詢參數超過5個時，封裝參數并使用 POST 請求。
雖然是基礎，但參數校驗是 API 安全的最后保障：
API是什么
API安全是什么
如何評估API 安全性
如何實施API 安全策略
7 大 REST API 安全威脅
