開店的人都懂一件事：鑰匙怎麼發，決定了誰能進門、進門之後能碰什麼。伺服器上的檔案也是這樣，只是那把「鑰匙」被寫成了一串三位數。你可能在某篇教學裡看過有人叫你把某個資料夾設成 777，看起來只是個湊巧的數字，實際上那等於把大門鑰匙留在門口，任何路過的人都能進來翻東西、加裝設備，甚至直接把鎖換掉。
多數人以為檔案權限是主機商在管的事、跟自己沒關係，但錯誤的權限設定其實是網站被植入惡意程式最常見、也最容易被忽略的破口之一。所謂 WordPress 檔案權限設定，就是替網站每一個檔案與目錄規定「誰能讀、誰能寫、誰能執行」，用一組數字表示。它不需要你懂太深的系統知識，只需要抓對兩件事：正確的數值該是多少，以及萬一發現設錯了，怎麼一次把整個網站不對的地方批次抓出來修好。
這篇就從權限那三個數字是怎麼算出來的講起，再一路帶到怎麼查、怎麼改、改完怎麼驗，最後拆掉幾個會害你越設越糟的迷思。
檔案權限是什麼？為什麼 WordPress 特別在意這件事
先把最底層的觀念講清楚。伺服器上的每一個檔案和目錄，都會針對三種身分各自規定一組權限。這三種身分分別是擁有者（owner，通常就是你的主機帳號）、群組（group，跟你同一組的其他帳號，例如網頁伺服器）、以及其他人（world／others，也就是這台伺服器上剩下的所有人）。用 WordPress 官方文件的話說，Linux 的檔案權限就是由這三塊組成：檔案擁有者有哪些權限、同群組的成員有哪些權限，還有其他任何人存取或修改這個檔案時有哪些權限。
每一種身分底下，又各自可以設三種存取權：讀（read）、寫（write）、執行（execute）。它們對應到固定的數字：讀是 4、寫是 2、執行是 1。你把某個身分要給的權限數字相加，就得到它那一位數。舉例來說，想讓擁有者能讀、能寫、能執行，就是 4＋2＋1＝7；想讓群組只能讀跟執行，就是 4＋1＝5。三種身分各算一位，湊起來就是你常看到的三位數，例如 755 代表擁有者 7（讀寫執行）、群組 5（讀＋執行）、其他人 5（讀＋執行）。
那為什麼同樣是網站，WordPress 對權限特別敏感？關鍵在於它是一套需要「動態寫入」的系統。純靜態網頁只要伺服器能把檔案讀出來丟給瀏覽器就夠了，權限可以收得很緊；但 WordPress 不一樣，你上傳一張圖片，它得把檔案寫進媒體庫；你更新一個外掛或佈景主題，它得覆寫掉舊的程式檔；它還會產生快取、暫存檔。這些動作全都要「寫入」權限。也就是說，WordPress 天生就得開一部分寫入的口子，而只要有能寫入的地方，就是攻擊者最想找的地方。這也是它的風險本來就比一般靜態網站高的原因。
為什麼「777」是最危險的組合？
不是每個高權限數字都一樣危險，777 值得單獨拉出來講，因為它幾乎踩滿了每一條紅線。這串數字翻成白話是：擁有者、群組、其他人，三種身分全都能讀、能寫、能執行。重點在最後那個「其他人」。它等於對整台伺服器上的所有帳號敞開，任何人都能往這個目錄寫東西，寫進去的東西還能被執行。
把攻擊鏈拆開看你就懂它多危險。假設你的上傳目錄被設成了 777，攻擊者甚至不用是什麼高手，只要在你的網站上找到一個能上傳的入口（可能只是一個看起來人畜無害的圖片上傳功能），他就能塞一支偽裝成圖片、副檔名卻藏著 PHP 的後門程式（業界俗稱 webshell）進來。因為那個目錄開了執行權限，這支後門一放進去就能直接被跑起來，等於在你的伺服器裡開了一道沒有鎖的暗門。WordPress 官方文件把後果講得很直接，一旦有惡意者能上傳或修改檔案來執行程式碼，他就能完全掌控你的網站，連帶拿走你的資料庫資訊和密碼。
呼應開頭那個比喻：755 和 644 是「留一把鑰匙給自己、東西讓客人看得到卻摸不到」，而 777 是連鎖都拆了，門就那樣開著。
WordPress 目錄與檔案的正確權限數值該怎麼選擇？
與其各憑印象記數字，不如記住一條主幹規則：目錄設 755、檔案設 644。這也是 WordPress 官方給的基準，所有目錄應該是 755 或 750，所有檔案應該是 644 或 640。之所以目錄和檔案給的數字不一樣，是因為「執行」這個權限對兩者的意義不同。對目錄來說，能不能「執行」決定了你能不能「進入」這個資料夾去看裡面有什麼，所以目錄需要那個 5（4＋1，讀＋執行）；但一般檔案（圖片、文章內容、樣式表）根本不需要被當成程式跑起來，所以拿掉執行權限、只留讀寫，就是 644。
這條基準適用於你網站裡絕大多數地方，包含 wp-content 以及它底下的 uploads、plugins、themes，這些都沒有例外，一樣是目錄 755、檔案 644。
不過有一件事要先講在前面，免得你等一下去比對自己的網站時嚇一跳。755／644 是「基準值」，不是唯一正確答案。不同的主機環境，會因為底層架構不同而正當地使用不同的數字。舉例來說，當你的網站是用另一個帳號（例如 FTP 帳號）在寫入、而不是伺服器本身那個帳號時，就得讓群組也擁有寫入權限，這時候權限就會比預設更寬鬆一階，變成目錄 775、檔案 664。這是 WordPress 官方文件也提到的常見情境。這種偏離基準的設定是主機商「刻意」這樣做的，不代表你的網站有問題。所以看到主機給的權限跟 755／644 對不上，先別急著手動改回去，那可能反而弄壞主機幫你調好的環境。
wp-config.php 為什麼要設得比其他檔案更嚴？
在所有檔案裡，wp-config.php 是唯一該被特別對待、設得比 644 更嚴的一支。原因很單純，它存著你的資料庫帳號密碼，還有 WordPress 用來加密登入狀態的一串金鑰。這是整個網站最值錢的一份檔案，一旦內容被別人讀走，等於把資料庫大門的鑰匙雙手奉上，對方連你的網站前台都不用碰，直接從後門搬空資料庫。
官方建議把它設成 440 或 400。440 是擁有者和群組可讀、其他人完全看不到；400 更嚴，只有擁有者自己能讀，而且兩者都不給寫入權限。這比預設的 644 嚴格得多，把「其他人能讀」這條路直接堵死。要提醒的是，有些主機環境不吃太嚴的設定，設成 400 之後 WordPress 更新設定時反而會失敗，這種情況才退一步用 640（擁有者讀寫、群組唯讀、其他人看不到）。原則很簡單，在網站還能正常運作的前提下，wp-config.php 收得越緊越好。
批次檢查全站權限有沒有設錯的方法
真正動手之前，順序很重要：先「查」，再「修」。很多人一看到教學裡有現成的修正指令，就直接複製貼上整站跑一遍，這其實很危險。萬一你的主機本來就有前面說的那種特殊設定，一道指令蓋下去，反而把好好的環境弄壞了。所以第一步永遠是先把「哪些地方不符合基準」列出來看清楚，確認真的該改，再改。
如果你的主機有 SSH 存取權限，查權限最快的方式是用指令。最基本的 ls -la 就會把當前目錄下每個檔案的權限、擁有者、群組都列出來；想連子目錄一起看，就用 ls -lR 遞迴列整棵目錄樹。針對某一支特定檔案想看得更仔細，可以用 stat 指令，例如 stat /你的網站路徑/wp-config.php，它會把權限、擁有者這些資訊攤得更完整。
更省事的做法是用 find 搭配條件，直接把「不符合基準」的檔案挑出來，而不用自己一行一行掃。像下面這樣，就能把所有權限不是 755 的目錄列出來：
find . -type d ! -perm 755Code language: Bash (bash)把 -type d（目錄）換成 -type f（檔案）、755 換成 644，就能列出所有權限不是 644 的檔案：
find . -type f ! -perm 644Code language: Bash (bash)跑完你會拿到一份「跟基準不一樣」的清單。這份清單要怎麼讀？它列出來的不一定全是錯的，照前面說的，主機刻意設的 775／664 也會出現在這裡。真正的用途是讓你一眼看到那些明顯出格的項目，尤其是任何一個 777，那幾乎可以確定是該修的。至於 FTP 客戶端（例如你平常拉檔案用的那套工具），其實它的檔案清單裡也有一欄會顯示權限，用滑鼠就能看，只是要靠人眼一個個目錄點開來核對，效率遠不如用指令一次批次掃出來。
批次修正權限的實作步驟
確認清單、知道哪裡該改之後，才進到修正這一步。下面這套指令的排列順序是有講究的：先目錄、再檔案、最後才單獨處理 wp-config.php，這樣才不會一道指令下錯就波及到不該動的檔案。每一步都附上它到底在做什麼，就算你不太熟指令，也能跟著跑。
Step 1，先備份整個網站，而且要連資料庫一起備。 這一步不能跳。批次改權限是對整站下手的動作，一旦哪裡估錯，影響範圍是全站，有一份完整的備份（檔案＋資料庫）你才有退路。這也是各家安全指南在教這件事之前，第一句都會叫你先備份網站的原因。
Step 2，把所有目錄批次改成 755。 進到你的 WordPress 根目錄，執行：
find . -type d -exec chmod 755 {} \;Code language: Bash (bash)這行的意思，是從目前所在的目錄往下，找出所有「目錄」（-type d），對每一個都執行 chmod 755，把它們統一設成 755。
Step 3，把所有檔案批次改成 644。 接著執行：
find . -type f -exec chmod 644 {} \;Code language: Bash (bash)跟上一步幾乎一樣，只是把條件換成「檔案」（-type f），統一設成 644。先跑 Step 2 再跑 Step 3，順序別顛倒，這樣目錄和檔案各自拿到對的數字，不會互相覆蓋。
Step 4，單獨把 wp-config.php 收緊。 前兩步是全站無差別處理，這一支要另外拉出來設嚴：
chmod 440 wp-config.phpCode language: Bash (bash)如果 440 之後遇到更新設定失敗，就退一步用 640；反過來說，如果你的環境撐得住更嚴的，用 400 也行。原則就是前面講的那句，能多嚴就多嚴。
Step 5，別忘了檢查「擁有者」對不對。 這一步最容易被漏掉，卻常常才是真正的關鍵。權限數字設對了，不代表就沒事。如果這些檔案的擁有者是錯的帳號，就算權限看起來很寬鬆，WordPress 一樣可能寫不進去。換句話說，擁有者有時候比那串數字更要緊。調整擁有者用的是 chown 指令，但它需要 SSH 或請主機協助處理，光靠 FTP 通常改不動。如果你權限都設對了、網站卻還是寫入失敗，這時就該回頭請主機幫你確認擁有者設定是不是對的。
修正後這三件事要重新測一遍，不是看首頁正常就結束
改完權限就當任務結束，是一個很常見的誤區。麻煩的是，權限設錯造成的問題（上傳失敗、更新失敗）常常在改完的當下看不出來。你重新整理首頁，畫面顯示一切正常，很容易就以為搞定了，其實真正會用到寫入權限的功能都還沒被碰過。首頁正常，只代表「讀取」沒問題，不代表「寫入」沒被你改壞。所以改完一定要主動把下面幾件事各測一遍：
第一、實際上傳一張圖片，確認媒體庫還能不能寫入。這是最直接檢查 uploads 目錄寫入權限的方式，能傳成功就代表這條路通了。
第二、更新一個外掛或佈景主題，看看寫入權限夠不夠。更新的本質就是覆寫舊檔案，如果權限或擁有者不對，這一步會卡住，剛好幫你把問題逼出來。
第三、進後台各個頁面點一圈，確認自己還能正常存取。這一步是在防「改太嚴」的反效果。權限收過頭，有時候擋住的不是駭客，而是你自己，導致後台某些功能打不開。
除了這三件事，如果你的主機能看到伺服器錯誤紀錄，也順手翻一下，看有沒有冒出新的、跟權限相關的錯誤訊息。這幾樣都過了，才算真的改完。
權限設錯最常出現的三種症狀，分別代表什麼問題？
反過來說，如果你是因為網站出了狀況才找到這篇，那先對號入座、找出你遇到的是哪一種，會比從頭讀更快。權限設錯最常表現成三種情境，成因和修法各不相同。
媒體上傳或外掛更新失敗。 你想傳圖卻一直失敗，或是更新外掛時跳出「無法建立目錄」之類的訊息，這多半指向寫入權限出了問題，通常是 uploads 或 wp-content 這些需要被寫入的地方權限不足；還有一種更隱蔽的情況，是權限其實夠，但擁有者不對，導致 WordPress 沒資格往裡面寫。對應的修法，就是回頭確認這些目錄是不是 755、檔案是不是 644，如果都對了還是失敗，就往擁有者那邊查。
前台或後台跳出 403 Forbidden。 403 的字面意思是「禁止存取」，在權限的情境下，多半是目錄的權限被設得太嚴，把「進入」或「讀取」這條路給擋掉了。伺服器要進這個資料夾拿檔案，卻發現自己沒權限進去，只好回你一個 403。把目錄設回 755 通常就能解。要補一句的是，403 不是只有權限一種成因，損毀的 .htaccess 檔、或某些安全外掛的規則也可能觸發同樣的錯誤，所以如果權限都確認正常了 403 還在，就要往這些方向再查。
白畫面或 500 錯誤。 這種通常出現在你「加固過頭」之後，把某些 WordPress 執行時必要的檔案權限收得太緊，緊到 PHP 連跑都跑不起來，整個頁面就白給你看，或直接回一個 500。這也是為什麼前面一直強調「越嚴不一定越好」。遇到這種，先別慌，把你剛剛動過的檔案權限放寬回 644、目錄放寬回 755，畫面通常就會回來。
這些權限設定的迷思，多一分保護不代表更安全
把幾個常見誤解拆掉，你才不會在「求安全」的路上把自己絆倒。
迷思一：權限跟基準不一樣，就是被駭或設錯了。 不是。前面反覆提過，主機環境會正當地使用不同的權限模型，suexec 架構跟 mod_php 群組寫入模式給的數字本來就不同。看到 775／664 這種偏離基準的組合，先想想是不是主機刻意調的，別一看到就當成入侵痕跡急著改。
迷思二：全部設成最嚴的 400 就最安全。 剛好相反。WordPress 本身就需要讀寫，你把該能寫的地方全鎖死，最先打不開網站的是你自己，不是攻擊者。真正的目標不是「越嚴越好」，而是「在網站還能正常運作的前提下，盡量收緊」。能動、又夠緊，才是對的平衡點。實務上多數運作正常的網站，根本不需要你去動它的權限：如果你的網站更新、上傳都正常，主機也是幫你裝好的，那就讓它維持原樣，別沒事去調。
迷思三：改檔案權限可以管住某個編輯不能亂改文章。 這是初學者最容易搞混的一組概念。檔案權限管的是「誰能讀寫伺服器上的實體檔案」，屬於作業系統那一層；而 WordPress 後台的使用者角色（管理員、編輯、投稿者）管的是「登入後台的人能在網站裡做什麼」，屬於 WordPress 應用程式那一層。這是兩套完全獨立的系統，你把 wp-config.php 改成 440，不會讓一個「編輯」角色沒辦法編文章；反過來，你想限制某個帳號的操作範圍，也不該去動檔案權限，那是後台角色權限要管的事。搞混這兩者，往往會讓你花力氣改了半天，結果根本沒解決到問題。
AI 幫你寫程式或裝外掛時，權限這件事更要盯緊
現在不少站長會用 AI 工具來快速加功能，像請它產生一段外掛程式碼、寫一支自動化部署腳本，貼上去就能動，很方便。但這裡有個容易忽略的坑：AI 給的程式碼範例，出發點常常是「先求你能跑起來、別卡在權限問題上」，所以它很可能順手建議你把某個資料夾直接開成 777，好讓測試階段什麼都寫得進去。問題是，測完之後那個 777 常常就被忘在那裡，一路帶上線。
所以有個習慣值得養成：凡是 AI 生成的、或你在論壇、討論串上抄來的程式碼裡出現 chmod 777 這種建議，都要先亮起一盞燈。這頂多只能是暫時、測試用的權宜手段。WordPress 官方也是這麼說的，777 只在必要時用，而且最好只用很短的一段時間。測試一過、功能確認能動，正式站上線前一定要把它改回 755／644 這組基準。別因為「AI 說這樣比較不會出錯」就照單全收，AI 圖的是讓程式碼跑得起來，不是替你顧網站的安全。
檔案權限不是設定一次就能永久放心的事。網站搬過家、換過主機、被人亂改過設定之後，權限很可能已經不是你以為的樣子，這種時候都值得回頭把前面那套批次檢查再跑一遍。鑰匙要收好，但也別為了怕被偷就把整扇門焊死——收得剛剛好，讓自己進得去、讓外人進不來，才是這件事真正的分寸。