如果能按照本文的這個清單來實踐，就能將網路安全方面的風險降得很低。
Web開發人員安全清單
在雲端開發安全又健壯的 Web 應用非常難。如果你認為這很容易，那你技術水平要麼已經很牛叉，要麼還沒有踩過坑。
如果你盲目接受最簡可行產品（Minimum Viable Product，簡稱 MVP），並且認為你能在一個月之內建立一個既有價值又安全的產品，那麼在你推出你的“產品原型”前，你還需要多想想。在你檢視了下面的清單之後，確認你不會犯這些嚴重的安全問題。至少，你要對你的潛在使用者坦誠，讓他們知道你還沒有一個完整的產品，並且只提供一個沒有全面安全的原型。
這個清單很簡單，並且也不是那種大而全的。我已經開發安全的 Web 應用有 14 年多了。這個清單包含了一些相對重要的問題。這些問題都是我在這段時間學到的，而這個過程也是痛苦的。當你在建立 Web 應用時，我希望你能夠認真地對待這些問題。
如果在這個清單中，你有我沒有提到的專案，請留言補充。
資料庫
- [ ] 可以識別使用者的資料和敏感資料（如訪問令牌、電子郵件地址或賬單資訊）需要加密。
- [ ] 如果你的資料庫在休息狀態時支援低成本加密（如AWS Aurora），那麼啟動該功能來保護硬碟上的資料。同時也要確保所有備份都是被加密儲存的。
- [ ] 給使用者最低訪問許可權的賬戶。不要使用資料庫的 root 賬戶。
- [ ] 刻意設計一個金鑰庫，用它儲存和分發機密內容。不要硬編碼到你的應用中。
- [ ] 通過只使用 SQL 預處理語句（prepared statements）的方法來完全防止 SQL 注入。比如：如果要使用 NPM，不要使用 npm-mysql，而是使用 npm-mysql2，因為它支援預處理語句。
開發
- [ ] 對於每個釋出的版本，確保軟體的所有元件都通過了漏洞掃描。元件指的是作業系統、庫和包。這應該自動地進入持續整合/持續交付流程。
- [ ] 保證開發系統的安全。同樣的，對於你使用的產品系統，也需要保持相同的警惕。在安全、隔離的開發系統中開發軟體。
認證
- [ ] 確保所有密碼都經過合適的加密方法（如 bcrypt ）的雜湊處理。永遠不要自己實現加密方法，並且用好的隨機資料來正確地初始化加密方法。
- [ ] 在實現登入、忘記密碼、密碼重置等功能時，用經過驗證過的最佳實現或元件。不要重複造輪子，因為你很難保證其在所有場景中都不會出現問題。
- [ ]遵循簡單且合適的密碼規則，鼓勵使用者使用較長的隨機密碼。
- [ ] 你們提供的所有服務，用多重認證來驗證登入。
拒絕服務防護
- [ ]確保網站不會因 API 遭拒絕服務攻擊（DOS）而癱瘓。至少，在相對較慢的 API 路徑上（像登入和 Token 生成程式）設定頻率限制器。
- [ ] 對使用者所提交的資料和請求，在大小以及結構這兩點上執行合理的限制。
- [ ] 通過使用全域性快取代理服務（類似 CloudFlare ）來規避分散式拒絕服務（DDOS）。如果網站遭到 DDOS 攻擊，你就能開啟這個服務和其他類似的，以作 DNS 查詢。
網路流量
- [ ] 整個網站都使用 TLS，不僅僅是登入表單和響應。 永遠不要只在登入表單中使用 TLS。
- [ ] Cookie 必須設定 httpOnly、安全、被路徑和域限定。
- [ ] 使用內容策略安全（CSP），並且不允許 unsafe-*（*是萬用字元）後門。雖然配置時很痛苦，但這是值得做的。
- [ ] 在客戶端的響應頭中使用 X-Frame-Option、X-XSS-Protection。
- [ ] 使用 HSTS 響應強制僅限 TLS 訪問。在伺服器上重定向所有 HTTP 請求到 HTTPS，作為替代方案。
- [ ] 在所有的表單中使用 CSRF 令牌（Token）。使用新的 SameSite Cookie 響應頭，這徹底解決了所有較新瀏覽器上的 CSRF 問題。
API
- [ ] 確保公開 API 中沒有可列舉的資源。
- [ ] 確保使用者經過全面的認證，並且擁有適當許可權的使用者才能訪問 API。
- [ ] 在 API 中使用隨機檢查，以檢測潛在攻擊的非法或異常請求。
驗證
- [ ] 為了給使用者快速的反饋，可以在客戶端做輸入合法性驗證，但是永遠不要相信使用者的輸入資料。
- [ ] 在伺服器端使用白名單，來驗證所有使用者的輸入。永遠不要直接將使用者的內容新增到響應中。永遠不要在 SQL 語句中使用使用者輸入的內容。
雲配置
- [ ] 確保所有的服務開啟儘可能少的埠。當隱晦式安全（security through obscurity）沒有保護的效果時, 將預設的埠替換成非標準的埠，這樣可以讓攻擊者更難攻破。
- [ ] 將後端資料庫和服務託管到私有 VPC 上 (虛擬私有云)，而 VPC 不能被任何公共網路訪問。當你在配置 AWS 安全組和對等 VPC 時，你需要非常仔細，因為這可能導致服務無意中對外部開放。
- [ ] 在隔離 VPC 和對等 VPC 裡隔離邏輯服務，以便支援跨服通訊。
- [ ] 確保所有服務接收的資料，來自於一個儘可能小範圍內的 IP 地址。
- [ ] 限制出站 IP 和埠流量，最大限度地減少 APT 攻擊帶來的損失和“通訊”。
- [ ] 始終使用 AWS 訪問管理（IAM）這個身份，而不是 root 憑據。
- [ ] 授予所有操作和開發人員最小的訪問許可權。
- [ ] 根據時間表定期地更換密碼和訪問金鑰。
基礎設施
- [ ] 確保你能在不停機的情況下升級。確保你能通過完全自動的方式快速升級。
- [ ] 使用像 Terraform 這樣的工具建立所有的基礎架構，而不是通過雲端控制檯。基礎架構應該被定義為“程式碼”，並且能夠按下按鈕來重建。對於任何在雲端手動建立的資源採取零容忍態度，之後 Terraform 就能審計你的配置了。
- [ ] 所有服務都使用集中式日誌架構。你永遠都不應該需要 SSH 來訪問或者檢索日誌。
- [ ] 除了一次性診斷，不要通過 SSH 連線到你的服務。通常使用 SSH 意味著你沒有自動執行重要任務。
- [ ] 永遠不要在任何 AWS 服務組上保持 22 號埠為開啟的狀態。
- [ ] 建立不變的主機，而不是不斷地給你長壽的伺服器打補丁和升級。(參見Immutable Infrastructure Can Be More Secure).
- [ ] 使用入侵檢測系統來最大化減少 APT 攻擊帶來的影響。
運營
- [ ] 關閉未使用的服務和伺服器。斷電的伺服器是最安全的。
測試
- [ ] 審計你的設計和實施。
- [ ] 做滲透測試。除了你之外，還可以叫其他人進行滲透測試。
培訓
- 就關於社會工程領域中的潛在威脅和相關防護技術，要對員工（特別是高階員工）進行培訓。
最後，制定一個計劃
- [ ] 做一個威脅模型，描述你正在防禦物件。按主次列出可能的威脅和參與者。
- [ ] 制定一份可實操的安全事故計劃。總有一天你會需要的。