外掛更新、密碼強度、雙重驗證，這幾件事幾乎是每一份 WordPress 安全檢查清單的固定班底，卻很少有清單會提醒你，回頭看看 wp-config.php 裡那組 DB_USER 與 DB_PASSWORD，也就是WordPress資料庫帳號，連進資料庫之後能做多少事。
多數人設定過 WordPress 的後台角色，管理員能做什麼、編輯能做什麼、訂閱者只能看什麼，卻沒意識到還有另一層帳號，權限範圍完全獨立於角色系統之外。這組資料庫帳密才是真正決定「網站被打穿之後，攻擊者能碰到多深」的關卡。資料庫最小權限指的就是，這組帳號只該擁有日常運作剛好用得到的操作範圍，多給一分都是平白多出的風險。多數安裝教學圖方便，直接把這組帳號設成能讀能寫也能砍表改結構，等於把攻擊者一旦拿到帳密後的行動上限，直接拉到跟 WordPress 本身一樣高。
先從這兩層機制有什麼差異講起，再一路拆到怎麼動手把權限收回來。
資料庫最小權限是什麼？
WordPress 的「使用者角色」管的是登入後台的人能按哪些按鈕，管理員能刪文章、編輯能發布內容、訂閱者只能留言；這一層寫在 WordPress 自己的資料表裡，跟 WordPress 本身的權限系統綁在一起。但真正連進資料庫本身的，是另一組完全不同的帳密，也就是 wp-config.php 裡的 DB_USER 與 DB_PASSWORD。這組帳號在 MySQL（或 MariaDB）這一層，能執行哪些指令，是只能 SELECT 讀取，還是連 DROP、ALTER 都能做，跟 WordPress 的角色系統完全無關。就算你把後台每個使用者都設成訂閱者，只要這組資料庫帳密的權限沒收緊，一旦外洩，攻擊者能做的事一樣不受限制。
這就是為什麼「最小權限原則」要拉到資料庫這一層來談。OWASP（開放全球應用程式安全計畫）在資料庫安全的建議裡講得很直接，開發者替資料庫使用者指派權限時，就該套用最小權限原則，讓這組帳號只擁有應用程式運作剛好需要的最少權限，不是圖方便就給多。放到 WordPress 的情境，意思很具體，這組資料庫帳號的權限範圍，只該對得上 WordPress 日常運作真正會用到的操作，不該因為「這樣比較省事」就多給。
多數安裝教學直接給資料庫使用者全部權限
問題是，多數人第一次接觸這組帳號，看到的示範幾乎都是同一種寫法。不少 WordPress 安裝教學，甚至虛擬主機自帶的一鍵安裝精靈，範例指令直接寫 GRANT ALL PRIVILEGES，把資料庫帳號設成對整個資料庫全部權限。理由不難理解，這樣裝完不管裝什麼外掛，都不會卡在「權限不足」的錯誤訊息上，維護起來最省事，久而久之就變成事實上的預設值。
網路安全業者 Acunetix 指出，授予全部權限對想完全掌控 WordPress 資料庫的人來說確實方便，但從安全角度來看極度危險，一旦駭客拿到這組資料庫的存取權限，他能對 WordPress 資料庫與裡面存放的資料做到的事，幾乎等同完全的控制權，對整個網站的安全會帶來嚴重後果。換句話說，這組帳密一旦外洩，或是被某個外掛的 SQL 注入漏洞打穿，攻擊者能做的事跟 WordPress 本身能做的事完全對等，不只能讀資料，還能改資料表結構、砍表，把整個資料庫清空。
外掛的 SQL 注入漏洞，踩的正是資料庫帳號的權限範圍
這不是紙上談兵的假設，SQL 注入本來就是 WordPress 外掛漏洞裡固定會出現的一類。資安公司 Patchstack 在 2025 年年中的漏洞報告裡，把當年上半年通報的 WordPress 漏洞依類型統計：跨站腳本（XSS）以 34.7%排第一，幾乎是第二名的兩倍；跨站請求偽造（CSRF）占 19%；本機檔案包含（LFI）占 12.6%；失效的存取控制（Broken Access Control）占 10.9%；SQL 注入排在第五，占 7.2%。比例看起來不高，但這個類別一旦命中，影響範圍直接觸及資料庫本身，這正是「權限範圍決定攻擊者能做什麼」這件事最具體的例子。
Patchstack 另一份《2025 年 WordPress 資安現況報告》裡列出的具體案例，能讓這件事更有畫面。安裝量達 70 萬的行事曆外掛 The Events Calendar，被抓出一個 SQL 注入漏洞，CVSS（通用漏洞評分系統）評分高達 9.3 分；安裝量 40 萬的備份與搬家外掛 WPvivid Backup and Migration，同樣出現 CVSS 9.3 分的 SQL 注入漏洞。報告對這類漏洞的實際影響講得很清楚，惡意攻擊者能藉此直接跟資料庫互動，不只限於竊取資訊。
這裡有一件事容易被搞混，資料庫帳號的權限範圍，決定的不是「這個外掛會不會被打穿」，而是「打穿之後，攻擊者能做到多深」。同一個 SQL 注入漏洞，如果背後那組資料庫帳號只有 SELECT、INSERT、UPDATE、DELETE 這四種權限，攻擊者頂多偷資料、竄改或刪除資料表裡的內容；但如果帳號還留著 DROP、ALTER 這些權限，攻擊者就能砍表、改資料表結構，甚至把整個資料庫清空。漏洞能不能被堵住，靠的是外掛本身寫得夠不夠嚴謹；打穿之後傷害多大，靠的就是資料庫帳號的權限設定。
WordPress 日常讀寫只需要四種基本權限
把風險放一邊，回到正面的答案。WordPress.org 的《Hardening WordPress》文件講得很明確，日常運作這組資料庫帳號只需要讀取與寫入這兩類資料權限，對應到 MySQL 就是 SELECT、INSERT、UPDATE、DELETE 這四種。你每天在後台做的事，幾乎全部落在這四種權限的範圍裡。
發布一篇文章，是 INSERT，新增一筆資料；回頭編輯已發布的內容、或在後台儲存一項設定，是 UPDATE，修改既有資料；把一則留言丟進垃圾桶，或清空回收桶，是 DELETE；至於前台每一次讀取文章、顯示留言、載入選單，靠的都是 SELECT，單純讀取。發文、編輯、清留言、上傳媒體、新增使用者、前台顯示內容，這幾件你每天在做的事對照一輪下來，全部只會用到這四種權限，拿掉其他權限完全不影響日常使用。
有一點容易被誤解，安裝外掛這個動作本身不需要額外的資料庫權限，WordPress 文件也把安裝外掛列在只靠這四種權限就能完成的日常操作裡。外掛是先以檔案形式被放進外掛資料夾，那一步靠的是伺服器的檔案系統寫入權限，跟資料庫權限無關；外掛啟用之後開始執行、要讀取設定或寫入資料時，用的也是上面這四種權限。
DROP、ALTER、GRANT OPTION 留著，都是沒設防的風險
確認完剩下的部分，除了這四種，其餘的結構與管理權限，其實都可以收回。WordPress 文件的說法是，除了讀寫這四種之外，其他任何資料庫結構與管理權限，像 DROP、ALTER、GRANT，都可以收回；收回這些權限，同時也是在強化圍堵政策，把帳號能造成的損害圈得更小。
逐一拆開來看，這幾個權限各自能造成的傷害都不小。DROP 能整個刪掉一張資料表，甚至整個資料庫，等於一鍵把網站砍掉；ALTER 能改資料表的結構，例如砍掉某個欄位、改變欄位型別，資料表本身還在，但結構一壞，整個網站多半就打不開；CREATE 能建立新的資料表，攻擊者可能藉此在資料庫裡埋一張別人看不出來的後門表。
這幾個裡面最危險的其實是 GRANT OPTION。這個權限一旦留在帳號上，代表這組帳號自己就能把手上的權限再轉發給別的帳號。攻擊者只要拿到這組帳密，再掌握主機上另一組既有帳號，就能藉 GRANT OPTION 把這個資料庫的存取權限轉過去當後門；就算你事後把原本那組密碼改掉，拿到權限的那組帳號還是能連進資料庫。這幾個權限對日常的 WordPress 發文、編輯、瀏覽完全用不到，只在特定時機才需要。
不過 WordPress 文件也留了一句提醒，收回這幾個權限不是沒有代價。外掛、佈景主題或 WordPress 核心的大版本更新，遇到需要異動資料庫結構的情況，如果這組帳號當下沒有 CREATE 或 ALTER 的權限，更新就可能出問題。這份文件甚至直接寫明不建議收回這些權限，並補充如果你真的要為了安全考量收回，要先確保自己有一套經過測試、隨時能還原的完整資料庫備份計畫。
臨時放寬權限只在外掛建表或核心大改版才用得到
收回權限不是一次設定就一勞永逸不用管，重點是抓準什麼時候才需要重新放寬。外掛或佈景主題第一次啟用時，常常需要 CREATE 自己的資料表，像表單外掛要存使用者送出的紀錄，電商外掛要存訂單資料；之後版本更新，有時也需要 ALTER 去調整既有的表結構。WordPress 核心的大版本更新，有時也會動到資料庫結構。原則很清楚，權限開來就是為了做這一件事，做完立刻收回，不是圖方便讓整組帳號長期開著。
外掛安裝與更新最常動到資料表結構
具體要怎麼判斷這個外掛裝完，要不要臨時開 CREATE？先看外掛本身的安裝說明，會另外存自己資料的外掛，像表單、電商、快取、會員或訂閱系統這類，安裝時通常要建自己的資料表，之後升級版本也可能異動表結構，這類外掛裝之前先臨時開 CREATE、ALTER 會比較保險。反過來說，純粹處理外觀的外掛，像字體管理、圖示庫這類，通常完全不會碰資料庫結構，不需要為它臨時開權限。
如果一時判斷不出來，還有一個很直接的辦法，先照日常的四權限裝裝看，裝完第一次啟用時，如果跳出資料庫寫入錯誤的訊息，那就代表這個外掛需要額外的結構權限，這時候再臨時開 CREATE 或 ALTER，裝完立刻收回即可，不必為了以防萬一提前把權限開好開滿。安全業者 Melapress 也提醒，有些更新確實需要額外權限，外掛升級版本時，可能會連帶更新它自己那些資料表的結構，這正是臨時放寬權限最常用到的時機。
核心版更新反而多半不必額外開權限
很多人以為 WordPress 核心版本更新才是最該提防資料庫結構跑掉的地方，實際上多數更新根本不會動到資料表結構。WordPress 文件的說法是，只有像 3.7 升 3.8 這種主版本升級才會改動資料庫結構，3.8 升 3.8.1 這類小版本更新一般不會。真正頻繁需要 CREATE 或 ALTER 的，反而是安裝新外掛，或是外掛做比較大的版本改版。這份文件把外掛、佈景主題、核心大版更新這三種情境並列在同一句提醒裡，說明這幾種情況都可能需要建立新表或改變資料庫結構，並沒有特別強調哪一種最常發生。
所以別把「更新 WordPress 前，先把資料庫帳號權限全部打開」當成固定流程來做，先照日常設定跑，遇到資料庫寫入錯誤再臨時放寬也不遲。同時也別走向另一個極端，把收回權限這件事看得太絕對，如果收得太緊，反而可能讓某次重要更新在毫無預警的情況下失敗。這也是為什麼 WordPress 文件特別提醒，收回這幾個權限的前提，是搭配定期、而且真的驗證過能還原的完整資料庫備份，備份計畫做好了，收放這組權限才不會綁手綁腳。
實際設定這組權限的三種入口
講完原則，回到怎麼動手。設定這組權限，常見的入口有三種，對應到不同的主機環境，做的其實是同一件事，只勾 SELECT、INSERT、UPDATE、DELETE，其餘不勾。
有 MySQL 指令列存取權限的人，常見於 VPS 或自己管理的主機，可以直接用 GRANT 語法設定，例如：
GRANT SELECT, INSERT, UPDATE, DELETE ON wordpress_db.* TO 'wp_user'@'localhost';Code language: SQL (Structured Query Language) (sql)這裡有一個容易忽略的細節，GRANT 語法裡的主機欄位，上面例子的 localhost，要明確填寫，不要留成萬用字元。MySQL 參考手冊說明，如果省略主機名部分，預設就會是%，代表允許從任何主機連線，這正是為什麼要把主機明確限定成 localhost 或特定 IP 的理由，把這組帳密能連線的來源鎖死，就算帳密外洩，對方也得先能連到那台主機才有用。
用 cPanel 虛擬主機的人，不需要打指令，在「Manage My Databases」這個管理頁面裡（cPanel 118 版以前叫「MySQL Databases」），替既有的資料庫使用者設定權限，畫面上會列出 SELECT、INSERT、UPDATE、DELETE、CREATE、ALTER、DROP 這些選項，把不需要的取消勾選即可。用 phpMyAdmin 管理資料庫的人，則是進到該資料庫的「Privileges（權限）」分頁，同樣是針對這個使用者帳號逐項勾選權限。
三種入口的操作介面不同，但做的是同一件事，確認這組帳號只保留 SELECT、INSERT、UPDATE、DELETE，其餘結構與管理權限取消。OWASP 對這組帳號的建議還有幾個原則值得一併注意。別用資料庫內建的 root 或管理員層級帳號來跑 WordPress，這組帳號也不該是資料庫本身的擁有者，擁有者身分本身可能造成權限被拉高的漏洞；而且只該連得到 WordPress 實際用到的那個資料庫，不該連得到主機上其他資料庫。
用角色或雙帳號取代反覆調整同一組權限
如果你常常要在日常四權限跟臨時多幾個權限之間來回切換，一直手動 GRANT、REVOKE 很容易漏改，也容易忘記在做完維護之後把權限收回去。這裡有兩種更穩妥的做法，分別對應不同的資料庫版本與操作習慣。
用 MySQL 角色一次管理多組權限的開關
MySQL 從 8.0 版開始內建角色功能，可以把整組權限包成一個角色，要提權的時候只是切換帳號目前套用哪個角色，不必重新一條條下 GRANT 或 REVOKE 指令。做法是先建立兩個角色，一個只給日常的四項讀寫權限，另一個多給 CREATE、ALTER 這類結構權限：
CREATE ROLE 'app_read_write', 'app_maintenance';
GRANT SELECT, INSERT, UPDATE, DELETE ON wordpress_db.* TO 'app_read_write';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER ON wordpress_db.* TO 'app_maintenance';Code language: SQL (Structured Query Language) (sql)接著把兩個角色都授予同一個使用者帳號，平常用 SET DEFAULT ROLE 把生效的角色切到日常版，要維護時再切到擴權版：
GRANT 'app_read_write', 'app_maintenance' TO 'wp_user'@'localhost';
SET DEFAULT ROLE 'app_read_write' TO 'wp_user'@'localhost';Code language: SQL (Structured Query Language) (sql)要臨時提權時，把上面最後一行的角色名稱換成app_maintenance即可，操作起來比逐條 GRANT、REVOKE 少犯錯，因為切換的是整組角色，不會漏改其中一項。要注意的是，角色功能是 MySQL 8.0 以後才有的能力，主機資料庫版本比較舊的話，這個做法用不了，要改用下面的雙帳號法。如果主機用的是 MariaDB，它也有角色功能，但指令寫法跟 MySQL 不同，例如設定預設角色要寫成 SET DEFAULT ROLE 角色名稱 FOR 帳號，上面的指令不能直接照抄，要照 MariaDB 文件的寫法調整。
拆成日常與維護兩組 MySQL 帳密，依用途切換
沒有 MySQL 角色可用時，主機版本較舊，或不想碰指令列，就直接建立兩到三組 MySQL 帳密分工：一組是日常四權限帳號，WordPress 平常運作就用它；另一組是維護專用帳號，多了 CREATE、ALTER、甚至 DROP 這類權限，只在真的要建表、改表的時候才拿出來用。
需要臨時擴權的時候，把 wp-config.php 裡的 DB_USER 與 DB_PASSWORD 手動改成維護帳號，做完該做的事，裝外掛、跑更新，立刻改回日常帳號，並且把維護帳號的密碼重新設定過，不讓它長期保持有效。
Melapress 也提醒一個容易被忽略的細節。如果這組帳號同時能連到主機上其他的資料庫，一旦出事，受影響的範圍就不只這個網站。所以不管哪一組帳號，都該限定它只能連得到自己該用的那一個資料庫。OWASP 對帳號分工的原則性建議也一致，認為每一組資料庫帳號理想上只服務單一一個應用程式或服務，不要讓好幾個網站共用同一組資料庫帳密。這個做法比角色法多了一道手動改設定檔的步驟，維護時得記得切換、記得切回來，但好處是完全不依賴 MySQL 版本，不管主機用的是哪一代資料庫，都能照樣操作。
調整後，用 SHOW GRANTS 確認生效與相容性
權限改完，不能只憑感覺覺得應該生效了，要實際查證。用 SHOW GRANTS 這道指令，可以直接列出這組帳號目前真正擁有的權限：
SHOW GRANTS FOR 'wp_user'@'localhost';Code language: SQL (Structured Query Language) (sql)如果是套用角色的情境，想連同角色展開的實際權限一起看，可以加上 USING 子句：
SHOW GRANTS FOR 'wp_user'@'localhost' USING 'app_read_write';Code language: SQL (Structured Query Language) (sql)跑完這行指令，逐一核對列出來的權限是不是只剩 SELECT、INSERT、UPDATE、DELETE 這四種，確認沒有多餘的結構或管理權限殘留。
接下來要做的是觀察網站實際運作有沒有異常。大多數情況下，前台瀏覽、後台發文編輯完全不受影響，因為這四種權限本來就涵蓋了日常會用到的每一種操作。如果某個特定外掛開始跳出資料庫寫入錯誤，而且錯誤訊息裡出現 CREATE TABLE 或 ALTER TABLE 這類字樣，代表這個外掛其實常態性需要建表或改表的權限，常見於某些快取外掛或安全外掛，它們會持續自建、自清暫存的資料表。遇到這種情況，不是每次都非收回不可，可以有兩種選擇，要嘛就把那項權限保留給它，承認這個外掛的運作方式本來就需要多一點空間；要嘛換一個不需要長期占用結構權限的替代外掛。收緊到什麼程度，終究要回頭配合自己實際在用的外掛組合去調整，不是套一組規則就能一體適用。
資料庫帳號的權限，平常不會有人主動去看，直到出事那一刻才會發現它決定了損害的上限。把這組帳密收到剛好夠用的範圍，做起來其實只是幾條 GRANT 指令、或是後台勾選畫面裡幾個核取方塊的事，換來的卻是外掛出漏洞、帳密外洩時，攻擊者能碰到的範圍被鎖在讀寫資料這一層，而不是整個資料庫任他處置。花一次時間把這組權限盤點清楚，之後每次裝外掛、做更新，才知道什麼時候該臨時放寬、什麼時候該立刻收回。