看懂網站弱點掃描報告：8 個最常見的發現與修補方法

做完一次網站弱點掃描，拿到的報告常常是一長串英文項目、紅橘黃色的標籤，再加上一堆 CVE 編號。很多站長看完第一個反應是「全部都要修嗎？先修哪個？」這篇文章用白話說明報告怎麼讀，並整理我們在客戶網站最常看到的 8 類發現與對應的修補方向。

提醒：本文內容都屬於防守端的設定與檢查，不涉及任何攻擊手法。掃描只應針對自己的網站，或已取得書面授權的系統進行。修改設定前，請先備份檔案與資料庫。

一、先看懂嚴重度：紅色不一定最急，灰色也不一定能忽略

嚴重度五級對照 CVSS 分數與處理時程，以及判讀每筆發現的三個問題 — 圖：嚴重度等級與判讀三問

大多數掃描工具會依 CVSS（通用弱點評分系統）把發現分成嚴重、高、中、低、資訊五級。CVSS 是通用的參考分數，它不知道你的網站實際長什麼樣子。所以拿到每一筆發現，建議先問自己三個問題：

真的存在嗎？很多項目是工具依「版本號」推測的。例如作業系統套件常以「回補修正（backport）」方式修補，版本號看起來舊，漏洞其實已經修好。先核對再動手。
碰得到嗎？任何人打開網址就碰得到的問題，比必須先登入後台才碰得到的問題急。
出事會怎樣？會導致資料外洩、網頁被竄改，還是只是多透露了一點資訊？

二、掃描報告最常出現的 8 類發現

掃描報告最常出現的八類發現：版本過舊、TLS、標頭、Cookie、版本外洩、敏感檔案、目錄列表、管理介面 — 圖：最常見的 8 類發現

1. 軟體版本過舊（有已知 CVE）

WordPress、Joomla 等套裝程式的核心、外掛、佈景，以及 PHP 本身，只要版本落後，報告就會列出一串已公開的 CVE。這通常是最該優先處理的一類，因為漏洞公開後，自動化的批次掃描往往很快就會找上門。過去我們處理過的入侵案例，有不少就是從太舊的網站編輯器或外掛進來的。

定期把套裝程式更新到最新版本；更新前先備份。
刪除沒在用的外掛與佈景。停用不等於安全，檔案還在就還能被存取。
確認 PHP 版本仍在官方支援期內；虛擬主機通常可在控制台切換版本。

2. TLS／憑證問題

常見項目有：仍允許 TLS 1.0／1.1 這類舊協定、使用弱加密套件、憑證即將到期或憑證鏈不完整、HTTP 沒有自動轉到 HTTPS、HTTPS 頁面混入 HTTP 資源（混合內容）。最後兩項也是瀏覽器把網站標示為「不安全」的常見原因。

只開放 TLS 1.2 與 TLS 1.3。舊協定的處理思路可參考關閉 SSL 3.0 這篇。
使用自動續約的免費 SSL 憑證，並定期檢查憑證狀態；已過期的可參考如何更新過期憑證。
設定全站 HTTP 轉 HTTPS，並把內文、佈景裡寫死的 http:// 資源改成 https://。

3. 缺少安全標頭

安全標頭是伺服器回應時附上的指示，告訴瀏覽器「這個網站要怎麼保護自己」。報告常見的缺項包括 HSTS（強制使用 HTTPS）、X-Content-Type-Options、X-Frame-Options（防止網頁被嵌入其他網站做點擊劫持）、Referrer-Policy、Permissions-Policy 與 CSP（內容安全政策）。在 Apache／LiteSpeed 主機上，可以透過 .htaccess 加入：

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

HSTS 要最後加：確認整站 HTTPS 都正常之後再開啟。設定後瀏覽器會在 max-age 期間內拒絕以 HTTP 連線，若要加上 includeSubDomains，所有子網域也都必須支援 HTTPS。
CSP 先觀察再上：CSP 寫錯會讓網站的外掛、統計碼或金流按鈕失效。建議先用 Content-Security-Policy-Report-Only 觀察一段時間，再改成正式模式。

4. Cookie 旗標不足

登入狀態通常存在 Cookie 裡。報告若指出 Cookie 缺少 Secure（只走 HTTPS）、HttpOnly（JavaScript 讀不到）或 SameSite（限制跨站送出），被竊取或濫用的風險就會提高。PHP 程式的工作階段 Cookie 可以在 php.ini 設定：

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"

程式自己另外發的 Cookie，則要在程式或外掛設定中確認，這部分通常需要開發者協助。

5. 版本資訊外洩

回應標頭裡的 Server、X-Powered-By，網頁原始碼裡的 generator 標記，或網站根目錄的 readme.html，都會透露你用了什麼軟體、哪個版本。這本身多半是低風險，但會讓自動化工具更快對上已知漏洞。

php.ini 設定 expose_php = Off，移除 X-Powered-By 中的 PHP 版本。
刪除安裝後用不到的 readme、license、安裝說明檔。
要記得：隱藏版本不等於修補。真正的解法仍然是第 1 項的更新。

6. 敏感檔案可以直接下載

這是我們認為最容易被低估的一類。常見例子包括：用 Git 部署後留在網站目錄裡的 .git/、存放資料庫密碼的 .env、打包在網站根目錄的備份檔（.zip、.sql、.tar.gz），以及測試完忘記刪除的 phpinfo 頁面。一旦這些檔案能被下載，等於把鑰匙交出去，需要立即處理。

備份檔不要放在網站根目錄；依 3-2-1 備份原則存放到網站以外的地方。
phpinfo 這類測試檔用完立刻刪除。
封鎖以點開頭的隱藏目錄與設定檔（保留 .well-known 給憑證驗證使用）：

RedirectMatch 404 /\.(git|svn|env)

如果發現 .env 或含有密碼的檔案曾經可以公開下載，光是封鎖還不夠，必須把裡面的資料庫密碼、API 金鑰全部更換。

7. 目錄列表開啟

當資料夾裡沒有 index 檔時，伺服器若開啟目錄列表，訪客就能看到整個資料夾的檔案清單，例如上傳目錄裡的所有檔案。在 .htaccess 加一行即可關閉：

Options -Indexes

修改後若出現 500 錯誤，代表主機不允許在 .htaccess 覆寫這個選項，請改由主機商協助設定，並注意資料夾權限是否正確。

8. 管理介面暴露

後台登入頁、WordPress 的 xmlrpc.php、phpMyAdmin 這類資料庫管理頁面，如果任何人都能存取，又沒有限制登入次數，就會長期承受密碼猜測攻擊。

使用不易猜到的管理員名稱與強密碼，並開啟兩步驟驗證。主機與網站的各類密碼設定也一併檢查。
限制登入失敗次數；要留意的設定細節可參考 Limit Login Attempts 封鎖 IP 的問題。
不需要遠端發文或 App 連線時，可停用 xmlrpc.php。
管理目錄可再加一層資料夾密碼保護，或只允許固定 IP 存取。

三、先修哪一個？用兩個問題排序

報告上的項目常常幾十筆，不可能同時處理。簡單的排序方式是把「任何人都碰得到嗎」與「出事後果多嚴重」放在一起看：

第一優先：公開就碰得到、後果又嚴重。例如 .env 或備份檔能下載、外掛有公開漏洞。當天處理。
第二優先：要登入才碰得到，但後果嚴重。例如後台外掛的漏洞，搭配密碼強化一起處理。
第三優先：公開可見但影響有限。例如缺少安全標頭、版本資訊外洩，排入下次維護一次改完。
定期檢視：其餘資訊性項目記錄下來，下次掃描時看有沒有變化。

四、修完要重掃：建立固定循環

修補完成後一定要重新掃描，確認該項目確實消失，而不是改錯檔案或被快取蓋住。另外，每次改版、安裝新外掛之後，以及平常每個月，都值得再跑一次基線掃描。每次掃描的日期、發現與處理方式要記錄下來，下一次才能比較「報告上的數字有沒有越掃越少」。

也別忘了掃描只能看到「從外面看得到的問題」。網站如果已經被入侵，還需要搭配查看 error log、檢查檔案與帳號異動等方式判斷，可參考網站被植入惡意程式的修復流程，以及網站被駭後如何避免再次被駭。

結語

弱點掃描報告不是成績單，而是一份待辦清單。先確認真偽、分出輕重，把「公開就碰得到又後果嚴重」的項目先處理掉，再用固定的掃描、修補、重掃循環慢慢收斂。大部分常見發現只要更新軟體、調整幾行設定就能改善，難的往往是持續做下去。

想了解掃描工具本身有哪些種類，可以延伸閱讀弱點掃描技術總覽（2026）；想建立網站防護的基本觀念，可參考入門的主機防護方式。