把實際發生的事故排在一起看，罕見的攻擊手法幾乎沒有出現。出現的是少數反覆出現的模式，而這些模式不依技術、而依背後的前提來分類，會更清楚。
① 以為預設值是安全的（什麼都沒設定）
為了方便開發而選的預設值
詳細的錯誤訊息 · 可以連到管理介面 · 寬鬆的權限
↓ 原封不動地上線
任何人來看都能看到內部細節
結構、路徑、版本和內部的值都能被讀到
- 正式環境開著除錯輸出
- 錯誤頁面是否暴露環境變數、檔案路徑或堆疊追蹤？開啟一個不存在的 URL，親眼看看回傳了什麼。各框架的細節請看框架指南
- 管理介面可以被連到
- 資料庫管理工具和管理主控台可以從網際網路連到。不要只依賴驗證，要再加上 IP 限制或網路層級的阻擋
- 標頭沒設定，或照抄過時的清單
- 請看哪些標頭仍然重要、哪些已經不重要。加上已淘汰的標頭反而可能有害
- 弱的儲存方式沒改
- 密碼的儲存方式，請看雜湊與加鹽。「有加密」不是對儲存方式的說明
- 更新已經停止
- 使用超過支援期限的語言、框架或 CMS。請看用機器監控相依套件和支援結束實際代表什麼
② 以為沒在用的東西無害（什麼都沒關閉）
**你的攻擊面，來自不再使用的東西的部分，比來自你建立的東西更多。**一旦某個東西不再被使用，它就會在沒人注意的情況下脫離監控和檢查。
- 機密留在公開目錄
.env、備份、傾印檔、設定檔。絕對不能放在公開目錄的東西／共享主機上的放置方式- 儲存空間仍然公開
- 開啟封鎖不會刪除既有的公開政策。公開的儲存貯體
- 懸空的 DNS 紀錄
- 刪除了資源卻沒刪 DNS 項目，任何人都可以取得那個名稱並接管子網域。子網域接管
- 註冊和管理路徑仍開著
- 開放註冊是否還開著？用 HTTP 實測，而不是讀設定檔（驗證與授權的差別）。不要讓一個可被猜到的 URL 成為唯一「隱藏」頁面的方法
- 以為已經解約的帳號
- 解約服務和刪除帳號是兩回事，在你刪除之前資料都會留著。主機服務商被入侵時該怎麼做
- 舊的金鑰、權杖和權限
- 離職同事的帳號、沒有期限的權杖、過寬的範圍。SSH 金鑰與最小權限／密碼管理器
盤點範圍不要只限於正在運作的東西
如果只檢查「目前在用的東西」，這種模式根本找不到。範圍要涵蓋你曾經建立的所有東西：子網域、帳號、金鑰、儲存貯體、測試環境、第三方訂閱。不再使用的東西，在刪除之前仍然是資產。清單的建立方法：資產盤點檢查清單。
③ 以為出事會發現（沒有監控）
損害的大小，與其說取決於入侵本身，不如說取決於它持續多久才被發現。而多數環境根本沒有發現問題的機制。
常見的狀態
・有存取紀錄，但沒有人看
・沒有驗證嘗試的稽核紀錄（所以事後無法還原「被看到了什麼」）
・設定了速率限制，但沒有人看得到它何時被觸發
・公開狀態是多層組合的結果，沒有任何一層能單獨回答
最後的結果是，對於是否出過事，只能說「不知道」。
值得具備的最低限度
・新使用者註冊時的通知（一個訊號就足以抓到異常）
・驗證成功與失敗的紀錄，並訂好保存期限
・用機器監控相依套件的漏洞（人追不上 → osv-scanner）
・記錄觸發限制的次數，並在暴增時發出警報（速率限制與濫用控制）
不需要全部都有。一個真正有效的發現問題的方法，就能防止事故拖成長期問題。
沒有紀錄時，誠實的答案是「不知道」，而不是「什麼都沒發生」
事件應變中最危險的做法，是把沒有紀錄當成什麼都沒發生的證據。沒有紀錄時，唯一站得住的說法是「不知道」；這種情況下，請以已被入侵為前提行動，更換所有可能已外洩的東西。組織的最低限度，請看組織的資安基本對策。
④ 以為驗證過的輸入是安全的
關於輸入，真正的問題不是「這個值是否正確」，而是「我讓這個輸入決定了多少事」。交出去的決定越多，驗證就越跟不上。
- 只有值
- 一般的輸入。長度、格式和範圍的檢查有效，屬於安全的一方
- 連結構也是
- 接收整個巢狀物件並合併的設計。原型污染
- 連型別也是
- 會重建物件的格式。攻擊在你的值檢查執行之前就已成功。不安全的反序列化
- 放到哪裡
- 上傳的檔案最後落在可以被執行的地方。檔案上傳漏洞
- 請求者是誰
- 信任請求標頭來決定用戶端的身分。X-Forwarded-For 偽造與受信任的代理
數一數你交出去的決定，就能看出危險的地方。而根本原因通常相同：想用驗證去解決應該用結構解決的問題。改變你接受的格式，比再加一道檢查更可靠。
依序進行
看看正式環境實際呈現的樣子（①）
不存在的 URL、會出錯的請求、管理路徑：用 HTTP 請求它們，看看回傳了什麼。重點是讀輸出，而不是讀設定。標頭可以用標頭檢查工具一次測完。
寫下你曾經建立的所有東西（②）
子網域、帳號、金鑰、儲存貯體、第三方服務。訣竅是不要用「是否仍在運作」來過濾。用資產盤點檢查清單建立清單，並把沒在用的項目一路處理到刪除（不只是停用）。
只建立一個發現問題的方法（③）
想一次建好完整的監控，結果通常是什麼都沒有。先從一個開始：新註冊通知、登入失敗暴增，或相依套件漏洞的郵件。一個就好，並確認它真的會觸發（設定了卻從未驗證過的監控，等於沒有監控）。
數一數你的輸入被允許決定什麼（④）
寫出外部資料決定的只有值，還是連結構、型別和目的地也一起決定。凡是決定超過「值」的地方，都是應該優先修改的地方。
把更新變成機制（避免 ① 再次出現）
第一種模式放著不管一定會回來。把相依套件和框架的更新交給機器監控，是唯一實際的答案（osv-scanner 入門／實用的 CVE 修補手冊）。只存在於文件中的程序，在忙碌的日子會最先被跳過。
本站的看法：這四種前提都曾經是對的
四者的共同點是，每一種在某個時間點都是正確的。開發期間預設值是合理的；沒在用的東西確實沒在用；規模小的時候你真的會發現；輸入驗證也確實解決了許多問題。正因如此，它們才沒有被重新檢查。
本站的立場是定期問自己：以前正確的前提，是從什麼時候開始不再正確的。這樣的檢查比增加更多技術更便宜，也更有效。也請注意兩者性質的不同：檢查清單告訴你該做什麼，卻不告訴你為什麼會漏掉；如果原因沒有改變，同樣的東西會在同樣的地方再次被漏掉。
延伸閱讀
- 作為步驟：資安基本對策檢查清單（個人與小團隊）／組織的資安基本對策
- 盤點：資產盤點檢查清單
- 從真實案例看：事故解析（同樣的模式一再出現）
- 趨勢：2026 年，攻擊者帶著帳密而來的情況多於利用漏洞
FAQ
Q資安應該從哪裡開始？
與其學習個別的攻擊手法，不如檢查自己的環境符合四種模式中的哪幾種，這樣更快見效。正式環境的設定是否還是預設值？有沒有建立後就沒關閉、仍然開著的東西？出事時你會發現嗎？你讓外部輸入決定了多少事？本文為每一種提供具體的檢查方法，並連結到更深入的文章。
Q小型的個人網站也適用嗎？
模式相同，優先順序不同。對個人或小團隊來說，最先見效的兩項是檢查預設值（正式環境是否開著除錯輸出？）和盤點沒關閉的東西（公開目錄中的機密、沒在用的子網域、閒置帳號）。可觀測性需要建置機制，可以稍後再做；但即使只有一個訊號，例如新使用者註冊時的通知，也能大幅縮短問題不被發現的時間。
Q這和檢查清單有什麼不同？
檢查清單告訴你該做什麼；本文談的是為什麼會漏掉。如果漏掉的原因沒有改變，列出項目也沒有幫助，同樣的東西會在同樣的地方再次被漏掉。四種想法都曾經是對的，所以才會在沒人檢查的情況下一直存在。需要實際步驟時，請從各節的連結進入檢查清單文章。
Q如果只有時間做一件事，該做哪一件？
在第三項（能夠發現）上改善一件事。前兩項放著不管會變成事故，但沒有第三項，你連事故發生了都不會知道。損害的大小，與其說取決於入侵本身，不如說取決於它持續多久沒被發現。保留紀錄、加一個通知、每月盤點一次：任何一項都是防止事故拖長、報酬最高的投資。