對象：正在維運 Java／Spring Boot 應用程式的人。這裡不談攻擊步驟，而是提供強化正式環境的實務參考（附優先度的檢查表、分領域對策、自我檢驗）。想看跨框架的全貌，請參閱 各框架資安對策的入口。
附優先度的強化檢查表
先由上而下實施這張表。P0 是前提，P1 是最頻繁的事故源，P2 是持續性的維護。
P0 ── 前提（先做這個）
相依套件 CVE 監控＋迅速修補／正式環境不顯示錯誤細節／機密外部化
P1 ── 最頻繁的事故源
Spring Security 的授權（預設拒絕、擁有者檢查）／削減 Actuator 與管理面的暴露
P2 ── 持續維護
不安全的還原序列化／標頭、CSRF、工作階段／SSRF
| 優先 | 對策 | 具體（Spring Boot） |
|---|---|---|
| P0 | 相依套件 CVE 監控 | osv-scanner / dependency-check；以實際執行版本判定、迅速修補（Log4Shell 系） |
| P0 | 正式環境錯誤 | 不對外顯示堆疊追蹤（server.error.include-stacktrace=never 等） |
| P0 | 機密外部化 | 連線資訊/金鑰改由 env/Vault 提供，不寫死在設定裡。別提交進版本庫 |
| P1 | 明示授權 | 預設拒絕＋方法授權（@PreAuthorize）＋擁有者檢查 |
| P1 | 削減 Actuator 暴露 | 最小暴露（例如 health）＋要求驗證＋獨立埠/邊界。別公開 env/heapdump |
| P1 | 還原序列化 | 別原生還原序列化不可信資料。別讓 SpEL 求值輸入 |
| P2 | 注入 | 用 JPA/JdbcTemplate 綁定。絕不用字串串接來組查詢 |
| P2 | 標頭/CSRF/工作階段 | Spring Security 的標頭（HSTS 等）、CSRF、cookie 屬性、工作階段固定對策 |
| P2 | SSRF | 伺服器端抓取採允許清單＋封鎖內部 IP/中繼資料 |
1. 相依套件 CVE 與生態系（P0）
正因為 Spring 被廣泛使用，**一個相依套件函式庫的漏洞就會同時影響眾多應用程式。**Log4Shell 是最知名的例子。
- 用 osv-scanner 或 OWASP dependency-check 對相依套件的 CVE 做機器監控，以實際執行版本判定、迅速修補（依實際建置的版本判斷，而非 pom.xml/gradle 的宣告）。
- 讓 **Spring Boot 與 Java 保持在受支援的版本。**別放任 EOL 版本。
- 案例與實務請參閱 Log4Shell 的剖析 · 漏洞應變實務 · 監控相依套件的 CVE。
2. 正式環境設定與機密（P0）
- 在正式環境不對外顯示錯誤細節（堆疊追蹤）——減少會洩漏內部結構與相依套件版本的線索。
- 把連線資訊、金鑰這類機密移出 application.properties/yml，改由 env 或機密管理工具（Vault 等）注入。別提交進版本庫（→ .env 檔與機密）。
- 別在正式環境啟用開發工具（devtools 等）。
3. Spring Security 的授權（P1 — 最大事故源）
常見（危險）
- 預設寬鬆，並非設計成明示允許
- 只靠 URL 樣式防守，沒有方法/擁有者檢查
- 已驗證，卻是「登入＝允許」
- 一個設定疏漏就讓某個端點對任何人開放
正確
- 預設拒絕（只有明示允許的才通過）
- 方法授權（
@PreAuthorize等）＋擁有者檢查 - 在每一條讀取/更新/刪除路徑上驗證權限/擁有者
- 明示地組建授權，別交給預設
參閱 什麼是 IDOR。驗證與授權是兩回事；在靠近資料的地方做授權。
4. Actuator 與管理端點（P1）
- 把暴露的 Actuator 端點收到最小（例如只留 health）。
- 要求驗證/授權，並把它們放在外部無法觸達的獨立埠／網路邊界之後。
- 別公開
env、heapdump、loggers這類敏感端點（資訊外洩／被濫用來執行未經授權的操作）。
5. 不安全的還原序列化與運算式求值（P2）
- 別原生還原序列化不可信資料（在特定條件下可能導致 RCE）。驗證來源，必要時限定為 JSON 等安全格式（→ 什麼是 RCE）。
- 別讓模板或 SpEL 求值使用者輸入。用 Bean Validation 等驗證輸入。
6. 注入與資料存取（P2）
- SQL：用 JPA / JdbcTemplate 綁定；絕不用字串串接來組查詢（→ 什麼是 SQL 注入）。
- 從模板輸出 HTML 時，做輸出編碼，別直接嵌入使用者輸入（XSS 防護）。
7. 標頭、HTTPS、工作階段（P2）
- 善用 Spring Security 的安全性標頭（HTTPS 時的 HSTS 等）。用 安全性標頭檢測 檢查自己的站台。
- **強制 HTTPS。**在負載平衡器之後，設定成能辨識正確的 scheme/用戶端 IP。
- 在 cookie 上設定 Secure/HttpOnly/SameSite，保留 CSRF 保護（瀏覽器工作階段預設啟用；若為了 API 而停用，要搭配替代的防護），並在登入時重新產生工作階段。
8. SSRF 與伺服器端抓取（P2）
- 伺服器端抓取使用者提供的 URL 時，應把目標限定在允許清單，並在連線時封鎖對內部 IP／雲端中繼資料的觸達（→ 什麼是 SSRF）。
檢驗：你的 Spring Boot 真的強化了嗎
建好不是結束——點檢過才算完成。以下是針對你自己環境的防禦性自我檢查。
Actuator 沒有暴露敏感端點
/actuator 沒有暴露 env/heapdump 等，而且有做驗證。錯誤不會洩漏內部
授權有效
相依套件與標頭
本站的觀點：重點放在相依套件與最小化公開範圍
Spring 是穩定的框架，但正因為被廣泛使用，一個相依套件函式庫的漏洞就會同時影響眾多應用程式。Log4Shell 是最知名的例子，而主要的防禦與其說是某個特定設定，不如說是「對相依套件做機器監控、以實際執行版本判定、迅速修補」的維運習慣。同時，別讓便利的管理端點（Actuator）暴露在網際網路上，也別把授權交給預設。本站是不同的技術棧，但原則相同：讓相依套件保持最新、把公開的範圍降到最小、把授權寫明確，不分框架都同樣有效。
接下來讀
- 入口：各框架資安對策 · Next.js 資安對策
- 案例／實務：Log4Shell 的剖析 · 漏洞應變實務 · 監控相依套件的 CVE
- 名詞：什麼是 IDOR · 什麼是 RCE · 什麼是 SSRF
- 工具：安全性標頭檢測
來源與確認範圍
以下原始資料支持上文的設定、影響範圍或應對措施，連結於2026年10月23日確認。請核對資料中的版本與設定條件。清單優先順序及經驗是本站的整理，不代表全文重新核驗或安全保證。