那道帶著“記住我”選項的登錄表單是大多數(shù)黑客故事的開場白。你寫下郵箱和密碼點擊確認(rèn)一束光沿著網(wǎng)線沖向服務(wù)器。此刻后端開發(fā)者若心存僥幸這束光就可能變成刺穿整個系統(tǒng)的匕首。安全不是功能而是地基下的鋼筋。用戶看不到它但每一次業(yè)務(wù)迭代、每一個新接口上線都在考驗它的承重。鑒權(quán)、加密與數(shù)據(jù)校驗這三件事做不扎實再漂亮的架構(gòu)圖也只是一張廢紙。鑒權(quán)別把“你是誰”和“你能干什么”混為一談很多團隊會犯一個經(jīng)典錯誤用同一個token既證明身份又判定權(quán)限。這就像把身份證和萬能鑰匙焊在一起撿到的人可以直接進你家臥室。鑒權(quán)Authentication與授權(quán)Authorization必須分離。前者回答“你是誰”后者回答“你能做什么”。OAuth2.0、JWT這類協(xié)議只是工具工具用錯了照樣流血。常見的JWT實現(xiàn)里有人把敏感權(quán)限直接寫進payload而不加密有人不設(shè)過期時間還有人把簽名密鑰硬編碼在代碼倉庫里。更隱蔽的坑是“越權(quán)”。水平越權(quán)你登錄自己的賬戶把URL里的訂單號改成別人的就能看到別人的訂單。垂直越權(quán)普通用戶直接調(diào)用管理員接口。后端必須默認(rèn)“最小權(quán)限”并對每個請求做資源歸屬校驗而不是只做登錄校驗。登錄成功只代表身份有效不代表請求合法。我的建議鑒權(quán)協(xié)議選業(yè)內(nèi)成熟的方案比如OIDC自己造的token體系大概率會在半年后變成漏洞分析報告的主角。同時令牌必須短期有效刷新令牌必須可撤銷。那些“為了用戶體驗”把token設(shè)成30天不過期的做法是把用戶賬號變成黑客的永久提款機。加密數(shù)據(jù)在傳輸和靜止時都要當(dāng)作裸奔來對待“我們用了HTTPS所以數(shù)據(jù)安全了?！边@句話的荒謬程度相當(dāng)于“我穿了雨衣所以跳水不會淹死”。HTTPS只保護數(shù)據(jù)在傳輸管道里的安全一旦數(shù)據(jù)落盤或者你通過后臺日志打到數(shù)據(jù)庫它就是一張貼在冰箱上的明信片。加密必須分層傳輸層用TLS存儲層用強加密算法。用戶密碼絕不能可逆加密必須用bcrypt、scrypt或Argon2這類慢哈希算法加鹽后存儲。為什么不用MD5或SHA-256因為GPU可以在秒級算爆普通哈希。慢哈希設(shè)計的目的就是讓每一次暴力破解都付出足夠高的時間成本。數(shù)據(jù)庫里的敏感字段比如手機號、身份證、銀行卡如果業(yè)務(wù)必須存儲明文至少要做字段級加密。但別迷信AES-128更不要自己設(shè)計加密協(xié)議。所有密碼學(xué)的最佳實踐只有一個核心原則算法公開密鑰保密。如果你發(fā)現(xiàn)自己在發(fā)明“獨特的異或變換”或者“自己改過的Base64”請立刻停手那是給黑客送人頭的姿勢。還有密鑰管理。很多團隊把密鑰放在配置文件里隨代碼庫一起提交。這是把保險柜鑰匙貼在保險柜門上。密鑰應(yīng)該存于專用管理體系如KMS或HSM并且定期輪換。一旦懷疑泄露立刻作廢重發(fā)。別等黑客替你完成這個動作。數(shù)據(jù)校驗過濾輸入不是靠前端“required”前端表單上的“必填項”星號僅僅是給用戶看的裝飾。后端必須假設(shè)所有輸入都是惡意構(gòu)造的。這個原則不是陰謀論而是成本權(quán)衡一次注入攻擊的破壞力遠超一萬次正常請求的便利性。SQL注入是最古老也最致命的漏洞。用拼接字符串的方式構(gòu)造查詢只要一個引號就能讓數(shù)據(jù)庫交出所有用戶的密碼哈希。正確的做法是永遠使用參數(shù)化查詢或ORM的預(yù)編譯語句絕不讓用戶輸入以任何形式直接拼進SQL語句中。XSS跨站腳本攻擊同樣能摧毀一個產(chǎn)品。用戶在評論區(qū)輸入一段JavaScript后端如果原樣存儲、原樣渲染那么每個看到這條評論的用戶瀏覽器都會執(zhí)行這段腳本。校驗和轉(zhuǎn)義必須在后端完成輸出時也要根據(jù)上下文編碼。前端框架的自動轉(zhuǎn)義幫不了你因為總有人會寫v-html或者innerHTML。類型校驗同樣重要。一個“年齡”字段后端如果只用字符串接收而不做范圍檢查那么不僅可能存進負數(shù)甚至可能存進SQL語句片段。數(shù)據(jù)校驗要分層次先檢查類型和格式再檢查業(yè)務(wù)規(guī)則。例如郵箱必須匹配正則數(shù)字必須在合理區(qū)間枚舉必須在白名單內(nèi)。任何不在預(yù)期范圍內(nèi)的輸入直接拒絕而不是強行轉(zhuǎn)換或忽略多余字段。別把日志變成第二場災(zāi)難日志系統(tǒng)記錄所有請求參數(shù)方便排查問題。這很常見但如果日志里包含密碼、token或完整銀行卡號那么日志文件就是黑客最喜歡的戰(zhàn)利品。日志中絕對禁止記錄敏感字段的明文。即使為了調(diào)試也只記錄脫敏后的摘要或掩碼。日志系統(tǒng)的權(quán)限控制往往比業(yè)務(wù)系統(tǒng)更弱一旦泄露后果不亞于數(shù)據(jù)庫被拖走。更隱蔽的是錯誤信息泄露。后端捕獲異常后直接把堆棧跟蹤返回給客戶端這等于給攻擊者畫了一張系統(tǒng)內(nèi)部結(jié)構(gòu)圖。對外暴露的錯誤信息應(yīng)該統(tǒng)一為“請求無效”或“服務(wù)器內(nèi)部錯誤”詳細原因只寫入日志且日志中不要記錄用戶輸入原文。你可以在日志中記錄user_id和錯誤碼但別記錄完整SQL語句和堆棧里的文件名。安全是持續(xù)對抗不是一次性上線很多團隊在安全評審時信心滿滿上線后就不管了。但漏洞是在代碼演進中逐漸長出來的新來的同事不熟悉規(guī)范寫了個不安全的反序列化第三方依賴庫爆出新的CVE某個業(yè)務(wù)為了查詢性能在數(shù)據(jù)庫里直接執(zhí)行了用戶輸入的字符串。所以必須做三件事第一依賴庫的漏洞掃描要進入CI流水線高危漏洞直接阻斷發(fā)布。第二代碼評審時安全清單要跟功能檢查表一樣重要每個接口都要過“鑒權(quán)、加密、校驗”這三道題。第三定期進行模擬攻擊或滲透測試不要只靠上線前的“安全自查”。如果你覺得這些步驟太繁瑣那請記住一個數(shù)字一次數(shù)據(jù)泄露的平均成本是事前預(yù)防成本的幾十倍甚至上百倍。而用戶信任一旦失去永遠不會回來。最后一道防線默認(rèn)信任的代價很多設(shè)計者喜歡“先信任后驗證”覺得這樣體驗流暢。但安全領(lǐng)域唯一的公理是你無法保護一個你從不懷疑的資源。每個請求、每個輸入、每個調(diào)用都必須通過“不信任”的默認(rèn)姿態(tài)來審視。這不是被害妄想而是數(shù)學(xué)上的必然——未經(jīng)驗證的輸入是無窮多種可能性而正確的處理只有一種。鑒權(quán)要驗身份和權(quán)限加密要護傳輸和存儲校驗要攔非法和惡意。這三件事不是三個孤立的模塊它們相互咬合鑒權(quán)失敗意味著加密的數(shù)據(jù)被錯誤的人訪問校驗失效則可能讓惡意載荷繞過鑒權(quán)直接執(zhí)行。作為后端開發(fā)者你手里握著用戶最敏感的數(shù)據(jù)。你的每一個if、每一次數(shù)據(jù)庫查詢、每一段日志輸出都是防線的一部分。不要用“應(yīng)該沒人會這樣傳參數(shù)”來安慰自己攻擊者的字典里沒有“應(yīng)該”二字。把這三條底線刻進每一個函數(shù)簽名里在寫代碼時多想一想如果我是黑客我會怎樣攻擊這個接口然后堵上它。安全沒有終點只有不斷逼近極限的防御。后端開發(fā)的榮耀不在于你寫了多少行代碼而在于你擋住了多少次那些永遠看不見的攻擊?，F(xiàn)在去檢查你那臺服務(wù)器上是不是還躺著一個三個月沒輪換的密鑰。