各框架對策
Spring Boot 的資安對策 — 正式環境強化實務參考
安全維運 Spring Boot 的實務參考。附優先度的強化檢查表，加上相依套件 CVE(Log4Shell 系)、正式環境設定與機密、Spring Security 的授權、Actuator/管理端點的暴露、不安全的還原序列化、注入、標頭/工作階段、SSRF 各項對策，以及自我檢驗。不含攻擊步驟，只講防禦與點檢。
對象：正在維運 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
- 工具：安全性標頭檢測
FAQ
Q要保護 Spring Boot，第一步該做什麼？
優先度 P0 的三件事：(1)對相依套件的 CVE 做機器監控並迅速修補，以實際執行版本判定（像 Log4Shell 那樣，地基級函式庫被繼承而同時波及眾多應用程式，追隨的速度才是關鍵）；(2)正式環境不對外顯示詳細錯誤（堆疊追蹤）；(3)把機密（連線資訊、金鑰）從設定檔外部化，別直接寫死。接著再進到 Spring Security 的授權與削減 Actuator 的暴露。
Q使用 Actuator 要注意什麼？
Actuator 提供取得執行資訊與診斷的管理端點，但一旦暴露就可能外洩內部資訊，依設定甚至成為操作的跳板。在正式環境要把暴露範圍收到最小（例如只留 health），要求驗證與授權，並置於外部無法觸達的獨立埠／網路邊界之後。別公開 env、heapdump、loggers 這類敏感端點。
Q如何為 Log4Shell 這類相依套件破口做準備？
Log4Shell 是被廣泛繼承的日誌函式庫破口同時波及眾多應用程式的典型案例。準備的重點是對相依套件的 CVE 做機器監控，並以『實際執行版本』判定、迅速修補（osv-scanner、OWASP dependency-check 等）——依實際建置的版本判斷，而非 pom.xml/gradle 的宣告。用最小權限與網路分段來縮小爆炸半徑同樣有效。
QSpring Security 的授權要怎麼寫才安全？
把預設偏向『拒絕』（只有明示允許的才通過），別只靠 URL 樣式，並在需要時使用方法層級的授權（@PreAuthorize 等）。在登入（驗證）之外，還要實作擁有者檢查——確認目標資源確實屬於該使用者。設定疏漏會變成權限提升的破口，所以授權要明示地組建。
Q不安全的還原序列化為什麼危險？
透過 Java 原生還原序列化來還原不可信資料，在特定條件下可能導致遠端程式碼執行（RCE）。別原封不動地還原外部來源的資料——驗證其來源，必要時限定為 JSON 等安全格式。同理，也別讓模板或運算式語言（SpEL）去求值使用者輸入。