本文節錄自Wiz, Inc.的Secure Coding Best Practices: Practical Guide + Cheat Sheet for Developers，這份文件的全文有10頁，不適合全部翻譯整理到資訊安全日報，有需要這份文件中文翻譯版本的讀者，可以來信索取。

Designing for the Environment（為環境進行設計）

安全設計始於評估應用程式的預期環境以及其將處理的資料性質。在撰寫邏輯之前，開發人員必須處理數個關鍵的環境問題：

Exposure（暴露性）：此應用程式是否對網際網路公開，或僅限於內部流量？

Data sensitivity（資料敏感性）：應用程式是否會處理敏感的 PII（Personally Identifiable Information，個人可識別資訊）、PHI（Protected Health Information，受保護健康資訊）或財務資料？

Identity and ownership（身分與擁有權）：誰擁有此應用程式，哪些系統或使用者被授權與其互動？

 

API-First Security Design（以 API 為先的安全設計）

由於 API 經常作為應用程式的入口，它們是攻擊者的主要目標。安全設計要求實作嚴格的驗證（authentication）與授權（authorization）機制，以防止未經授權的存取。

Authentication standards（驗證標準）：設計應採用 OAuth 2.0 以促進安全的第三方互動，並使用 JSON Web Tokens（JWT，JSON 網路權杖）進行無狀態驗證，以減少會話管理的負擔。

Defense-in-depth（縱深防禦）：導入多重要素驗證（MFA，Multi-Factor Authentication）以提供超越單一密碼的安全層。

 

Input and Resilience Patterns（輸入與韌性模式）

為韌性進行設計意味著假設輸入可能是惡意的，且資源可能會被耗盡。

Schema enforcement（結構綱要強制）：設計應用程式使用 schema 驗證（例如 JSON schema）在處理之前嚴格強制所有輸入的結構與限制。

Throttling and rate limiting（節流與速率限制）：為防範拒絕服務（DoS，Denial-of-Service）攻擊及過度的伺服器負載，設計應包含速率限制政策，限制單一使用者或 IP 在特定時間內可發出的請求數量。

Secure failure modes（安全失敗模式）：錯誤與例外應被設計為安全失敗。這包含清理日誌以移除敏感資訊，並向使用者提供通用錯誤訊息，同時僅供內部審查安全地記錄詳細的堆疊追蹤。

 

Secure Coding Best Practices（安全編碼最佳實務）

安全編碼在進入生產之前很早就開始。儘管現代軟體包含基礎設施、流程管線與協調層，許多持續存在的安全問題仍源自應用程式邏輯。本指南專注於實用的設計與編碼模式，有助於在漏洞變得可被利用之前，及早降低風險。
 

資料來源：Wiz, Inc, Secure Coding Best Practices: Practical Guide + Cheat Sheet for Developers