很多人是在網站出問題的那一刻，才第一次認真面對 WordPress 檔案權限設定。外掛裝不起來、媒體上傳失敗、後台跳出「無法建立目錄」，於是上網一查，看到有人說「把權限改成 777 就好了」，照做，問題真的消失了。但這個動作等於把家裡大門拆掉換成布簾，門開不開的問題是解決了，代價是任何人都能走進來。

檔案權限決定了「誰能讀、誰能改、誰能執行」你伺服器上的每一個檔案與資料夾。設得太鬆，惡意程式可以隨意寫入後門、竄改你的程式碼；設得太緊，WordPress 連自動更新跟上傳圖片都做不到。這篇會把 chmod 的數字邏輯講清楚，給出每一類檔案的建議數值，再帶到 wp-config.php 這個最敏感檔案的額外保護，以及幾個寫在設定檔裡就能擋掉大半攻擊面的強化參數。讀者群預設是自架 WordPress、用得到 FTP 或 SSH、想把站台守好的站長與開發者。

chmod 的三個數字到底在說什麼

權限數值之所以看起來像天書，是因為它把三組資訊壓進了三個數字。Linux 把每個檔案的存取對象分成三種身分：擁有者（owner，通常是你的 FTP 帳號）、群組（group）、其他所有人（world，也就是除前兩者外的任何人）。每一種身分各有三種能力：讀取（read）、寫入（write）、執行（execute）。

這三種能力用數字相加表示，規則固定：

• 讀取（r）= 4
• 寫入（w）= 2
• 執行（x）= 1

把一個身分擁有的能力數字加起來，就是那一位數。三個身分各算一次，依「擁有者、群組、其他人」的順序排成三位數，就是你在 FTP 軟體或 chmod 指令裡看到的權限碼。

以最常見的 755 為例：擁有者是 7（4＋2＋1，讀寫執行全有），群組是 5（4＋0＋1，能讀能執行、不能寫），其他人也是 5。換句話說，只有檔案主人能修改，其他人只能看、能進入資料夾。再看 644：擁有者 6（讀＋寫）、群組 4（只讀）、其他人 4（只讀）——這正是一般檔案最常用的設定。

資料夾的「執行」權限意義跟檔案不同。對資料夾而言，執行權限代表「能不能進入這個目錄、能不能讀取裡面的清單」，所以目錄通常要帶 x（數字尾數是 5 或 7），檔案則多半不需要 x（尾數是 4 或 6）。這也是為什麼目錄用 755、檔案用 644，兩者尾數差一個 1 的由來。

WordPress 各類檔案的標準權限數值

先給結論，再解釋例外。一個用 SSH 或 FTP 帳號管理的單站台，標準設定是：所有資料夾 755、所有檔案 644、wp-config.php 收緊到 640 或 600。任何檔案或目錄都不該出現 777。

下面這張表把 WordPress 安裝裡會碰到的主要對象整理出來：

WordPress 官方文件特別點名：wp-config.php 安裝時是用 644 建立的，放著不管是個風險，應該主動強化。這個檔案存放資料庫主機、帳號、密碼，以及認證金鑰與 salt，是整個站台最敏感的單一檔案，後面會單獨開一節處理。

至於整站要怎麼一次設定到位，用 SSH 的人可以靠 find 分別處理目錄與檔案，避免把所有東西都套同一個值：

# 進到 WordPress 根目錄後執行
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 640 wp-config.php

第一行只挑目錄設 755，第二行只挑檔案設 644，最後單獨把 wp-config.php 收到 640。沒有 SSH、只能用 FileZilla 這類 FTP 軟體的人，則是對著資料夾按右鍵選「檔案權限」，輸入數字後可勾選「遞迴套用到子目錄」，但同樣要分兩次做：一次套目錄、一次套檔案，不要對整棵目錄樹套同一個數字。

為什麼 777 修好了問題卻是最糟的選擇

777 的意思是擁有者、群組、其他所有人通通可讀、可寫、可執行。它之所以「有效」，是因為它把所有可能卡關的權限問題一次全部放行——但這正是它危險的原因。一旦某個目錄是 777，任何能在伺服器上跑程式的身分，包含被入侵的其他帳號、被劫持的 PHP 行程，都能往裡面寫檔案。

實務上常見的劇本是這樣：上傳功能壞了，站長把 wp-content 整個 chmod -R 777，問題消失，於是就這樣放著。問題在於這個動作不只放行了你要的寫入，也把整棵目錄變成任何人都能丟檔案、改檔案的開放空間。攻擊者只要找到一個能寫入的點，就能上傳 PHP 後門，接著就能讀到你的資料庫設定、拿到密碼、完全控制整個站台。曾有案例是把 wp-content 設成 777 後僅僅兩天，安全掃描就標記主機已遭入侵。

更關鍵的觀念是：權限問題的根因，幾乎都不是「權限數字不夠大」，而是「檔案的擁有者跟伺服器執行身分對不上」。你用 FTP 登入的帳號，跟 Apache、Nginx 實際跑網頁時使用的身分（常見的是 www-data、apache 或 nobody），往往不是同一個。當這兩者錯位，WordPress 就會寫不進檔案，看起來像權限太小，其實是擁有權（ownership）設錯了。正確做法是調整擁有者或群組，而不是把權限開到 777 來硬蓋過問題。

如果真的遇到非開放寫入不可的情境，官方建議的做法是從低往高試：先試 744、再 755、764、766，逐級往上，能動就停，而不是一步跳到 777。多數情況下需要的權限都不會超過 767。

怎麼修正被改亂的權限與擁有權

接手一個別人經手過的站，最常見的就是權限被改得亂七八糟——有時是前一手開發者，有時是主機商在搬站時動過手腳。與其一個一個檔案慢慢點，不如用一段腳本把整站權限與擁有權一次重置回標準狀態。

下面這段是社群長年流通的修復腳本骨架，邏輯是先把全站歸位成目錄 755、檔案 644，再針對 wp-config.php 與 wp-content 做差異化處理：

#!/bin/bash
WP_OWNER=www-data   # 伺服器上的執行身分
WP_GROUP=www-data   # 對應的群組
WP_ROOT=$1          # WordPress 根目錄

# 重置擁有權與基礎權限
chown -R ${WP_OWNER}:${WP_GROUP} ${WP_ROOT}
find ${WP_ROOT} -type d -exec chmod 755 {} ;
find ${WP_ROOT} -type f -exec chmod 644 {} ;

# 收緊 wp-config.php
chmod 640 ${WP_ROOT}/wp-config.php

WP_OWNER 跟 WP_GROUP 要填的是你主機實際的執行身分，不同主機商不一樣，不確定就問主機商客服或看主機面板。執行身分對了，多數「寫不進去」的問題會在重設擁有權後就自動消失，根本不必碰 777。

這裡要提醒一個共享主機常見的特例：有些主機採用 suexec 架構（PHP 行程以檔案擁有者的身分執行）。在這種環境下，PHP 本來就以你帳號的身分跑，所以即使目錄只是 755 也能正常寫入，wp-config.php 甚至可以更嚴格地設成 440 或 400，只讓擁有者讀取。判斷自己是不是這種環境最快的方式，是看後台更新外掛時會不會跳出要你輸入 FTP 帳密的視窗——會跳，通常代表執行身分與你的檔案擁有者不同；不會跳、直接就裝好，多半就是 suexec 這類能直接以擁有者身分寫入的設定。

wp-config.php 的額外保護：搬家、改權限、擋直連

wp-config.php 值得單獨拉出來講，因為它一旦外洩，等於資料庫帳密跟所有金鑰都送給了攻擊者。除了前面說的把權限收到 640 或 600，還有三個層次的保護可以疊加。

第一層是搬移位置。WordPress 有個少為人知的機制：如果它在根目錄找不到 wp-config.php，會自動往上一層目錄找。因此你可以把 wp-config.php 移到網站根目錄的上一層（也就是 web root 之外），讓它根本不在瀏覽器能觸及的範圍內。對單站台來說這是相當乾淨的隔離方式，不過共享主機或多站環境要先確認上一層目錄是不是你獨享，否則可能反而曝險。

第二層是用伺服器設定擋掉直接連線。Apache 環境可以在根目錄的 .htaccess 加上規則，拒絕任何對 wp-config.php 的外部請求：

<files wp-config.php>
order allow,deny
deny from all
</files>

如果你的站跑在 Nginx 上，就沒有 .htaccess 這回事，要改在 server 區塊裡用 location 規則擋下對應檔名，邏輯一樣是禁止外部直接存取設定檔。

第三層順帶處理 uploads 目錄。媒體上傳目錄必須可寫，卻也常是攻擊者試圖丟入 PHP 後門的首選位置。在 wp-content/uploads 放一個 .htaccess，禁止該目錄執行 PHP，就能讓即使被丟進來的惡意 .php 檔也跑不起來：

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

寫進設定檔就生效的三個強化參數

權限與擁有權是檔案系統層的防線，wp-config.php 裡還有幾個常數能從應用層再補一道牆。把它們加在 /* That's all, stop editing! */（也就是「編輯到此為止」那行註解）之前即可。

停用後台檔案編輯器。WordPress 後台預設內建外掛與佈景主題的程式碼編輯器，一旦管理員帳號被攻破，對方可以直接在這裡改檔案植入惡意碼。加上這行就能整個關掉編輯器畫面：

define( 'DISALLOW_FILE_EDIT', true );

進一步鎖死所有檔案異動。比上一個更嚴格的是 DISALLOW_FILE_MODS，它連從後台安裝外掛、上傳佈景主題、更新核心都一併禁止。安全性最高，但代價也最實在：你會失去一鍵安裝與自動安全更新，往後每次更新都得手動透過檔案系統處理。適合那種「上線後幾乎不動、由專人維運」的站台：

define( 'DISALLOW_FILE_MODS', true );

強制後台走 HTTPS。FORCE_SSL_ADMIN 確保登入與後台操作的密碼、cookie 都經過加密傳輸，不會以明文在網路上跑：

define( 'FORCE_SSL_ADMIN', true );

這三個參數不需要動到任何檔案權限，純粹是改設定檔就生效，屬於投報率很高的強化動作。要留意的是 DISALLOW_FILE_MODS 會連帶停掉自動更新，啟用前先想清楚後續的更新流程由誰負責。

把權限設定維持在對的狀態，比設好一次更重要

WordPress 檔案權限設定的核心其實只有兩句話：目錄 755、檔案 644、wp-config.php 再收緊，然後永遠不要用 777。背後的判斷依據是最小權限原則——只給每個檔案完成它該做的事所需的最低存取權，需要可寫的地方才開放可寫，其餘一律收緊。

但權限不是設一次就一勞永逸。搬站、換主機、某次為了除錯臨時開大的權限忘了改回來，都會讓站台慢慢偏離安全基準。建議把前面那段重置腳本留著，搬站或接手新站時跑一次校正；wp-config.php 的位置、權限與那幾個強化常數，則當成上線檢查清單的固定項目。權限數字本身不難，難的是把它維持在對的狀態——而這恰好是攻擊者最常鑽的縫隙。