各框架資安對策

WordPress 市占最大，統計上就是最大的標的。入口與其說是核心，不如說是外掛／佈景主題的漏洞、跳過更新、脆弱／重複使用的管理員，以及暴露在外的管理介面（wp-admin/xmlrpc/REST 列舉）。防禦：自動化核心＋外掛更新、刪除未使用的外掛／佈景主題、管理員採用強密碼＋2FA、限制管理後台的暴露與登入嘗試、竄改偵測加上離線備份。

Laravel 內建相當安全的預設值，但多數事故來自維運。三大陷阱：(1) .env 或機密檔案能從公開目錄透過網址讀取到；(2) 正式環境的 APP_DEBUG=true 會在錯誤頁面上暴露環境變數與連線資訊；(3) 缺少授權（登入＝驗證，但沒有依擁有者範圍界定的授權／Mass Assignment 覆寫非預期的欄位）。防禦：機密放在 public 之外並設權限 600、正式環境關閉除錯＋設定快取、以 Policy/Gate 授權、宣告 $fillable。

Next.js 的預設偏安全，但事故發生在『伺服器與用戶端的邊界』。三大＝(1)環境變數的暴露（誤用 NEXT_PUBLIC_ 或把伺服器專用的機密送到用戶端）(2)Server Actions / Route Handlers 的授權疏漏（有驗證但缺少擁有者範圍）(3)相依套件的已知 CVE（含框架本體的 RCE，以正式環境實際版本判定並迅速修補）。守法＝機密限定在伺服器、意識到邊界、在每個 Server Action 確認授權、對相依套件 CVE 做機器監控。

Express 是最小主義＝預設幾乎不內建資安功能，因此防禦要由開發者『自己補上』。重點＝(1)安全性標頭（helmet 相當）(2)輸入的驗證與淨化(3)不只驗證、還要有擁有者範圍的授權(4)速率限制（暴力破解／DoS 對策）(5)相依套件（npm）的 CVE 監控＋迅速修補。此外，對外抓取 URL 要做 SSRF 防護，機密放在環境變數、不混進程式碼。最小框架的自由，換來的是自己承擔防禦的責任。

Spring（Spring Boot）是企業級常青。事故的類型＝(1)相依套件的已知 CVE（像 Log4Shell 那樣被廣泛繼承的地基破口，以正式環境實際版本判定並迅速修補）(2)Actuator 等管理/診斷端點的暴露（資訊外洩、操作）(3)Spring Security 的授權設定疏漏（有驗證但權限檢查太鬆）(4)不安全的反序列化。守法＝對相依套件 CVE 做機器監控並迅速修補、收緊 Actuator/管理面、明示授權、不對不可信資料做反序列化。

Django 是『電池內建』並備有安全的預設（ORM、CSRF、樣板自動跳脫、認證），設定正確就很穩固。但事故來自設定。三大＝(1)正式環境 DEBUG=True，把設定、環境變數、機密暴露在錯誤頁面上(2)SECRET_KEY 外洩（簽章／工作階段的基礎）(3)授權太薄（缺少 is_staff／權限檢查）。此外還有 raw()/extra() 或字串串接造成的 SQLi、不安全的反序列化（pickle）、未設定 ALLOWED_HOSTS，以及相依套件（pip）的 CVE。防禦＝正式環境 DEBUG=False、SECRET_KEY 從環境變數載入、把授權寫明確。

Rails 內建慣例與安全的預設（CSRF 保護、Strong Parameters、ORM），用得正確就很穩固。但事故來自維運。三大＝(1)Strong Parameters 放得太寬而導致 Mass Assignment（被覆寫 is_admin 等）(2)授權作得太薄（有登入＝驗證，卻沒有擁有者範圍）(3)gem（相依套件）的已知 CVE。此外還有 where 的字串串接造成的 SQLi、危險的動態方法（send/constantize），以及 credentials/secret_key_base 外洩。防禦＝收緊 permit、把授權寫明確、監控 gem 的 CVE。

ASP.NET Core 是成熟穩固的地基，但事故來自設定。三大＝(1)正式環境暴露詳細錯誤／開發者例外頁面（內部資訊外洩）(2)機密直接寫進 appsettings.json（改用 User Secrets／環境變數／Key Vault）(3)漏掉授權屬性（[Authorize]）。此外還有不安全的反序列化（BinaryFormatter 等）、模型繫結的過度接收（用 DTO/[Bind] 限制），以及 NuGet 相依套件的 CVE。防禦＝正式環境隱藏詳細錯誤、機密從設定外部載入、把授權寫明確。