WordPress 後台「外觀 → 佈景主題檔案編輯器」與「外掛 → 外掛檔案編輯器」是兩個很方便、卻也很危險的功能。它讓管理員不必碰 FTP，就能直接在瀏覽器裡改 PHP 檔案。問題在於，這份權限不是只屬於你——只要有人拿到任何一組管理員帳密，就能用同一個編輯器，把一段惡意 PHP 寫進佈景主題或外掛裡，留下長期潛伏的後門。

絕大多數教學講到這裡就停在「在 wp-config.php 加一行 DISALLOW_FILE_EDIT」。這只關掉了「從後台改檔」這一條路，卻沒處理另一條更常被利用的攻擊面：攻擊者把 webshell 上傳到 wp-content/uploads/，再直接用網址呼叫它執行。真正要縮小後門植入面，得把「停用後台檔案編輯」和「限制 PHP 執行位置」一起做。

這篇會說明 WordPress 後台檔案編輯停用該怎麼設定、DISALLOW_FILE_EDIT 與 DISALLOW_FILE_MODS 的差別、如何禁止 uploads 目錄執行 PHP（Apache 與 Nginx 都給設定），以及這些設定擋得了什麼、擋不了什麼。

後台檔案編輯器為什麼是高風險的後門入口

後台檔案編輯器之所以危險，是因為它把「寫入伺服器 PHP 檔案」的能力，綁在了「登入後台」這個門檻上。一旦這個門檻被突破，編輯器就成了現成的植入工具。

WordPress 內建兩個這類編輯器，位置依佈景主題型態而不同。傳統佈景主題在「外觀 → 佈景主題檔案編輯器」與「外掛 → 外掛檔案編輯器」；區塊佈景主題（使用站台編輯器）則移到「工具」底下的「佈景主題檔案編輯器」與「外掛檔案編輯器」。不論在哪，它們做的事一樣：讓擁有 edit_themes 或 edit_plugins 權限的使用者，直接讀寫站台的 PHP 原始碼。

攻擊鏈通常是這樣：攻擊者透過暴力破解、外洩的密碼、或某個外掛漏洞，先拿到一組管理員身分；接著打開佈景主題編輯器，挑一個幾乎不會被注意的檔案（例如佈景主題的 404.php 或某個函式庫檔），貼進一段能接收外部指令的 PHP，存檔。從這一刻起，他不再需要登入後台——只要用瀏覽器存取那個被汙染的檔案網址，就能執行任意指令。這就是所謂的「後門」：一個繞過正常驗證、長期保留的遠端進入點。

停用後台檔案編輯不會讓你失去改檔能力。你或你的開發者，仍然可以透過 SFTP、SSH 或主機控制台的檔案管理員去改任何佈景主題與外掛檔。你拿掉的只是「瀏覽器裡的捷徑」，而那條捷徑對攻擊者的價值，遠大於對你的價值。

DISALLOW_FILE_EDIT 怎麼設定才會生效

最可靠的做法是在 wp-config.php 裡定義 DISALLOW_FILE_EDIT 常數，這是 WordPress 官方支援的設定，不依賴任何外掛，更新核心後也不會被覆寫。

wp-config.php 位於 WordPress 安裝的根目錄，通常在主機的 public_html 或其子資料夾裡。動手前先用 SFTP 或主機檔案管理員下載一份備份，避免改壞了沒有退路。打開檔案後，往下找到這一行：

/* That's all, stop editing! Happy blogging. */

在這一行的上方加入：

define( 'DISALLOW_FILE_EDIT', true );

存檔後（用 SFTP 的話要重新上傳）回到後台，檢查上一節提到的編輯器位置。如果「佈景主題檔案編輯器」與「外掛檔案編輯器」的連結都消失了，就代表生效了，即使用管理員帳號登入也看不到。

設定要放在 require_once ABSPATH . 'wp-settings.php'; 這一行之前，這也是為什麼要加在「stop editing」註解上方——加到那行之後等於沒定義，常數不會被讀到。

設定後編輯器還在的常見原因

如果改完編輯器連結還在，依序檢查這幾點。第一、清掉瀏覽器快取與站台快取，許多快取外掛會把後台選單一起快取住。第二、確認你改的是正在運作的那個 wp-config.php，有些主機有多份或有暫存版本。第三、檢查語法，少一個分號、引號用成全形、或誤用了智慧引號，都會讓整行失效，甚至讓網站出現錯誤。第四、確認沒有安全外掛或自訂程式碼，又把這個設定覆寫回去——部分安全外掛（例如 Sucuri、Wordfence 一類）有自己的開關，會在儲存設定時重新寫入這個值。

需要還原時把設定註解掉

用 wp-config.php 控制的好處是還原很乾淨。要恢復編輯器時，與其刪掉整行，建議改成註解：

// define( 'DISALLOW_FILE_EDIT', true );

存檔後編輯器就會回來。改完急用時拿掉註解最快，用完把斜線補回去即可，不必重打整行、降低打錯的機會。

DISALLOW_FILE_EDIT 與 DISALLOW_FILE_MODS 差在哪

兩個常數的差別在「鎖的範圍」：DISALLOW_FILE_EDIT 只關掉後台的檔案編輯器；DISALLOW_FILE_MODS 則連帶封掉所有從後台進行的檔案異動，是更嚴格的一層。

具體來說，啟用 DISALLOW_FILE_MODS 後，除了編輯器消失，還會擋掉從後台安裝外掛、上傳佈景主題、以及更新外掛、佈景主題與核心。換句話說，即使一個管理員帳號被攻陷，攻擊者也無法透過後台介面塞進惡意外掛或佈景主題壓縮檔——這正是另一種常見的後門植入手法。

設定方式與前一節相同，在 wp-config.php 的「stop editing」註解上方加入：

define( 'DISALLOW_FILE_MODS', true );

DISALLOW_FILE_MODS 的範圍已涵蓋 DISALLOW_FILE_EDIT，所以兩個不必同時設，啟用前者即可。它適合上線後就不常變動、把穩定性與安全性看得比後台便利性更重的正式站；缺點是每次要裝外掛或更新，都得改回設定或改走 SFTP，對更新頻繁的站會比較綁手。

實務上常見的折衷，是平常開著 DISALLOW_FILE_MODS，需要做大版本維護時，暫時把它註解掉、完成後再開回來。決策關鍵是看更新節奏：站台維護愈頻繁，愈可能只用 DISALLOW_FILE_EDIT；愈接近「設定好就不太動」的正式站，愈值得直接上 DISALLOW_FILE_MODS。

禁止 uploads 目錄執行 PHP，補上真正的後門出口

關掉後台編輯器，只堵住了一條植入路徑；攻擊者更常用的另一條，是把 PHP 後門透過漏洞上傳到 wp-content/uploads/，再直接用網址呼叫它執行。要縮小後門面，必須讓這個目錄即使被放進 PHP 檔，也無法被執行。

uploads 目錄理應只放圖片、PDF、文件這類媒體檔，沒有任何正當理由要在這裡執行 PHP。設定一道「這個資料夾裡的 PHP 一律不准執行」的規則，等於把上傳型後門的最後一哩——「執行」——直接切斷：檔案就算被放進去了，呼叫它也只會得到拒絕存取，跑不起來。

Apache 主機用 .htaccess 阻擋

如果主機是 Apache（多數共享主機、含 cPanel 環境），在 wp-content/uploads/ 底下新增一個 .htaccess 檔，內容如下：

<Files *.php>
  deny from all
</Files>

這段規則會對該目錄與其所有子目錄裡、副檔名為 .php 的檔案一律拒絕存取。新版伺服器若使用 Apache 2.4，部分環境改用新語法，可改寫為：

<Files *.php>
  Require all denied
</Files>

設定後可以做個簡單驗證：在 uploads 裡放一個只印出文字的測試 .php 檔，用瀏覽器直接開它的網址。若回應的是 403 或拒絕存取、而不是把內容執行出來，就代表規則生效。測試完記得把測試檔刪掉。

Nginx 主機改在站台設定檔加 location 規則

Nginx 不讀 .htaccess，得在站台的伺服器設定檔裡加規則。在對應 server 區塊中加入：

location ~* /wp-content/uploads/.*.php$ {
    deny all;
}

存檔後重新載入 Nginx 設定（例如 nginx -s reload）才會套用。這類設定通常需要主機或伺服器層級的權限，若你用的是受管型主機而無法改設定檔，可以直接請主機商協助加上「uploads 目錄禁止執行 PHP」這一條，多數供應商都熟悉這個需求。

設定前要留意一個例外：少數外掛或快取機制，會在 uploads 底下產生需要被執行的 PHP（這種設計本身不理想，但確實存在）。若擋了之後出現功能異常，先確認是哪個檔被擋，再針對該路徑做例外，而不是整條規則拿掉。

設定完該怎麼確認真的鎖上了

設定容易，但「以為設好了、其實沒生效」才是真正的風險。把停用後台編輯與禁止 uploads 執行 PHP 都做完後，逐項確認一遍，才算真的把面縮小。

確認後台編輯器這一側：用管理員帳號登入，按佈景主題型態到對應位置，確定「佈景主題檔案編輯器」與「外掛檔案編輯器」都看不到。若用了 DISALLOW_FILE_MODS，再到「外掛 → 安裝外掛」確認上傳與安裝鈕也已停用。

確認 uploads 這一側：用上一節的測試 .php 檔，從瀏覽器存取它的完整網址，看到拒絕存取而非執行結果，才算成功，驗證後刪除測試檔。

最後做一次盤點：除了這兩道設定，常被忽略卻同樣有效的是收斂權限。檢查所有使用者角色，只把管理員權限給真正需要的人，其餘給足夠完成工作的最低權限即可。後台檔案編輯與檔案異動，本質上都是綁在高權限帳號上的能力，帳號權限收得愈緊，被攻陷後可植入的面就愈小。

這些設定擋得了什麼、擋不了什麼

把預期說清楚，才不會誤以為做了這幾步就高枕無憂。DISALLOW_FILE_EDIT 與禁止 uploads 執行 PHP，封的是「拿到管理員身分後用編輯器寫後門」和「把 webshell 上傳到 uploads 再執行」這兩條具體路徑，這也是實務上最常見的兩種植入手法。

但它們不是萬靈丹。這些設定擋不了以下情況：攻擊者利用某個外掛或佈景主題本身的程式漏洞，在合法的程式目錄裡執行惡意碼；或透過 DISALLOW_FILE_MODS 未涵蓋的途徑（例如直接拿到 SFTP、SSH 或資料庫權限）改動檔案。也就是說，這幾道設定縮小的是「面」，不是把風險歸零。

正因如此，它們應該被當成多層防護裡的其中一層，而不是全部。搭配一起做才有意義的，至少包括：所有帳號使用夠長、夠獨特的密碼，並開啟兩步驟驗證（2FA）；持續更新核心、外掛與佈景主題，把已知漏洞補掉；以及建立可還原的定期備份，並實際測過還原流程，確保真的出事時救得回來。

回到最初的目標：縮小後門植入面，本質是把每一條「能寫入並執行伺服器程式碼」的路徑逐一收窄。停用後台檔案編輯，關掉了最方便被濫用的那條；禁止 uploads 執行 PHP，切斷了上傳型後門的執行點；收緊管理員權限，則讓帳號被攻陷後可動用的能力降到最低。三件事都不難，今天就能在 wp-config.php 與 uploads 設定裡完成，剩下的就是養成定期更新與備份的習慣，把這層防護長期維持住。