WordPress 安全加固：保護網站與身分的逐步指南

審閱日期：2026 年 9 月 27 日

WordPress 帳戶安全並非單一設定，而是一連串關於誰可登入、你暴露哪些軟件、以及如何復原的決定。官方 WordPress 加固指南把安全定義為「降低風險」而非「消除風險」，這才是合理期望。本文先說明 WordPress 通常從哪裡被入侵，再逐步示範你今天可以在正式網站上採取的行動。

風險實際來自哪裡

大部分 WordPress 事故都可追溯至幾個原因：管理員密碼太弱或重複使用、外掛或主題未更新、整合被賦予超出需要的權限，以及從未測試過的備份。隱藏登入網址或 WordPress 版本並不能解決以上任何一項。以下步驟針對真正重要的成因。

步驟 1 — 盤點帳戶與整合

列出每個使用者、每個應用程式密碼及每個第三方連接。員工離職當日就移除其帳戶，並撤銷不再使用之整合的權杖。你無法保護已遺忘的存取權。

步驟 2 — 修正認證方式

用密碼管理器管理唯一密碼。長度比強制複雜度更重要。現行 NIST 指引（SP 800-63B）偏好長密語，容許至少 64 個字元，並建議以已知外洩密碼清單篩查新密碼，而非強制組合規則及定期更換。
使用應用程式或硬件雙重認證。TOTP 應用程式與安全金鑰比 SMS 驗證碼更強；後者可被截取或透過 SIM 卡交換破解。
情況許可時使用 passkey。Passkey 與硬件金鑰（WebAuthn／FIDO2）可抵抗釣魚，因為它們無法被輸入到偽冒登入頁。WordPress 核心並未內建雙重認證或 passkey 登入，需靠保安外掛或主機／身分供應商登入提供。

步驟 3 — 套用最小權限

大部分撰寫內容的人都不需要管理員角色。給每人完成工作所需的最低角色，並保留至少兩個管理員以免被鎖在門外；應用程式密碼只用於確實需要它的整合。

步驟 4 — 修補核心、主題與外掛

WordPress 7.1.2 於 2026 年 9 月 22 日發布，緊接 9 月 17 日的 7.1.1 維護及安全更新。公開回報的 WordPress 漏洞大多來自外掛與主題而非核心，因此修補是最有價值的例行工作。可行時啟用自動更新；涉及自訂程式碼時先在測試站驗證；並刪除不再使用的東西——停用的程式碼仍留在伺服器上，仍需維護。

步驟 5 — 收窄暴露面

全站以 HTTPS 提供並將 HTTP 重新導向。
依官方加固指引：正確的檔案擁有者與權限、收緊 wp-config.php 權限、以 DISALLOW_FILE_EDIT 停用內建檔案編輯器，並使用只有 WordPress 所需權限的資料庫使用者。
如無必要整合使用 XML-RPC，封鎖它。
網站應用防火牆與登入頻率限制可減少自動化濫用，但它們屬補償控制——不會修復有漏洞的外掛或弱密碼。
加入 HSTS、Content-Security-Policy、X-Content-Type-Options 等保安標頭。

步驟 6 — 真正復原過的備份

從未復原過的備份只是假設。官方備份指引建議保留三至五份近期副本並存放於不同位置；常見的 3-2-1 原則（三份副本、兩種媒體、一份異地）是合理下限。備份要加密並限制存取，因為外洩的備份等於網站與資料庫的完整副本。要測試復原，而不只是執行備份。

步驟 7 — 監察與準備應變

定期檢查使用者清單、外掛、排程工作與檔案完整性。警號包括你未建立過的管理員帳戶、陌生的檔案或 <code>mu-plugins</code>、非預期的對外郵件，以及無故出現的轉址。若網站被入侵，先保留日誌與快照才清理，輪換所有憑證及 <code>wp-config.php</code> 的 WordPress salts，從事故前的備份復原，然後更新並重新掃描。

快速檢查清單

每個管理員在密碼管理器中都有唯一密碼。
管理員帳戶強制使用雙重認證或 passkey。
已移除不再使用的使用者、外掛、主題及應用程式密碼。
核心、主題與外掛已更新，自訂程式碼已在測試站驗證。
已強制 HTTPS，並套用官方指引的加固設定。
異地備份已加密，且已測試復原。
你知道事故首小時要聯絡誰、要做甚麼。

Managed-WP 如何協助你

Managed-WP 提供受管 WordPress 雲端託管，包括 24/7 支援、代管更新與備份，以及網站應用防火牆。若你不想獨自承擔以上清單，或想有人協助套用到正式網站，可到價格頁比較方案、了解WP 保安與 OWASP 服務，或使用下方即時聊天告訴我們你的網站情況。