多數人一聽到「自己的網站有一個 wp-json 網址，什麼東西都查得到」就緊張，直覺想把它整個關掉。其實真正該在意的從來不是已發布的文章與頁面，那些內容本來就設計成公開讀取，訪客在前台一樣看得到，REST API 只是換一種格式把它吐出來，不構成額外風險。真正該擋的是另一件事，/wp/v2/users 這個端點會把有發文作者的名稱、作者 slug 與使用者 ID 整批攤開，而且不需要登入就能查。
限制WordPress REST API存取，說的就是把這種不該公開的一小塊資訊收起來，不是把整組 API 關掉。這件事沒有聽起來那麼單純，掌握一批真實存在的使用者名稱後，暴力破解只剩「猜密碼」這一步，而官方也早就把「整組關掉」這個選項收回去了，filter 才是唯一的路。
哪些風險真的該擋、官方為什麼不讓你關閉、限制的力度又該怎麼選，這篇一次拆給你看。先從 REST API 攤開了什麼資訊講起。
使用者名稱外洩是 REST API 真正該擋的風險
REST API 讀得到的東西分兩層，已發布的文章與頁面本來就設計成公開讀取，被 REST API 讀到是正常行為，不是漏洞；真正該處理的是使用者資訊。/wp/v2/users 會把作者的顯示名稱、作者 slug 與使用者 ID 攤開給任何造訪者，不需要先登入，而作者 slug 在預設安裝下多半就是照登入帳號產生的。
這支端點的回傳範圍在 WordPress 4.7.1 修補過一次。WordPress 4.7 對作者清單的限制不足，被 NVD（美國國家漏洞資料庫）登記為 CVE-2017-5487，CVSS 3.0 評分 5.3 分，屬中度風險：修補前，只要在任何公開文章類型發過文，使用者資料就會被列出；修補後限縮成只列出在「有設定顯示於 REST API」的文章類型發過文的使用者。一般文章這個類型預設就是開著的，所以典型網站上發過文的作者，今天依然不必登入就查得到，「未登入即可查詢」這個性質並沒有變。
掌握使用者名稱後，暴力破解只剩猜密碼一步
WordPress 後台登入本身沒有內建帳號鎖定或速率限制，WordPress 的安全文件也是建議把登入嘗試的限流交給 WAF、CDN、網頁伺服器或安全外掛處理，沒做這層防護的站台，任何人都能反覆嘗試登入。攻擊者一旦先從 /wp/v2/users 拿到一批有效帳號，暴力破解與密碼填充原本要同時猜的「帳號」與「密碼」兩個未知數，就只剩密碼一個，成功率與效率都會跟著拉高。OWASP（國際非營利資安組織）在 API Security Top 10 把「認證機制薄弱」（Broken Authentication）列為第二名，濫用外洩帳號資訊去做憑證填充、暴力破解，正是其中被點名的高風險攻擊模式，「先查名單、再猜密碼」這條攻擊鏈不是危言聳聽。
官方已不再提供完全關閉 REST API 的開關
想把 REST API 整組關掉的念頭，在技術上其實已經行不通，官方連開關本身都收回去了。
REST API 的內容端點從 WordPress 4.7 版（2016 年底）起就內建在核心，不是外掛加上去的附屬功能，後台的區塊編輯器就靠它運作。過去若想整組關閉，rest_enabled 這個 filter 是常見做法，但這個 filter 在 4.7.0 就已經被標記為棄用。官方在棄用訊息裡直接寫明，REST API 已經無法再被完全關閉，要限制存取請改用 rest_authentication_errors 這個 filter。
WordPress 官方的 REST API Handbook，常見問題集的第一條就在回答「能不能關閉 REST API」，原文立場很明確，不應該停用 REST API，這麼做會弄壞依賴這個 API 運作的 WordPress 後台功能；但可以用一個 filter，要求呼叫 API 的一方必須先通過身分驗證，這樣就能有效阻擋匿名的外部存取。官方給的答案不是「關不關」，而是「怎麼限制存取」。
完全關閉之後，編輯器、表單與外部串接會先斷線
官方不建議關閉不是說說而已，代價會直接反映在你每天在用的功能上。
區塊編輯器透過 REST API 讀寫文章內容，載入區塊資料、儲存草稿、上傳圖片，背後都是在打 REST API 請求，跟按下發佈鍵那一刻背景在打 REST API 請求是同一套機制。把 REST API 整組鎖死、連已登入的使用者也一起擋掉，編輯器第一個出問題，而且常常不是明顯的錯誤訊息，是「存檔沒反應」「圖片上傳沒有回應」這種不容易第一時間聯想到 REST API 的症狀，排查起來反而更花時間。
受影響的不只是後台。不少外掛的免登入互動功能，實際運作也靠 REST API 做前端的非同步傳輸，像是不要求訪客先登入就能送出的聯絡表單，或是訪客不用註冊會員也能走完的結帳流程，這類匿名操作常見的實作方式就是讓前端直接呼叫 REST API。如果你的網站有串接第三方 App，或是用 headless 架構把前端跟 WordPress 分開，情況會更明顯，連訪客瀏覽公開內容，都可能是靠 REST API 在傳資料，鎖太緊等於前台也一起看不到。
限制存取有兩種力度，效果與副作用不同
官方 FAQ 說的「改用 filter 限制存取」，聽起來像一個做法，實際上分成兩種力度，效果與副作用有不小的落差。
官方 FAQ 舉的例子，是把 is_user_logged_in() 搭配 rest_authentication_errors 這個 filter，要求所有 API 使用者都先登入，這是其中一種做法，而且是最重的力度，匿名存取會被整組擋下。另一種做法只精準拔除特定端點，不動其他公開內容的存取。這兩個 filter 都是 WordPress 核心內建的機制，不是外掛才有的能力，不裝外掛也能做加固。
全站要求登入會連帶擋住訪客的合法操作
官方 FAQ 給的範例邏輯很單純，在 rest_authentication_errors 這個 filter 裡，先檢查前面有沒有其他驗證方式已經處理過這次請求，避免蓋掉別的驗證邏輯判斷出的結果；如果都還沒處理過，就檢查 is_user_logged_in()，沒有登入就回傳一個帶 401 狀態碼的 WP_Error。這是官方文件裡唯一示範的完整邏輯，效果是所有 REST API 請求都得先登入，沒有針對特定端點放行的機制，設定邏輯單純，效果也徹底，使用者清單這種高風險端點會跟著全部端點一起被擋下。
代價就藏在「全部」兩個字裡。任何原本設計成不需要登入就能用的 REST 互動都會一起被擋，訪客免登入送出表單會失敗、訪客走結帳流程時背景呼叫的 REST 端點會被拒絕、headless 前端讀取公開內容的請求也會一併碰壁。這個做法適合沒有這類對外互動的站台，純內容型、形象展示型，沒有會員系統、沒有電商結帳、也沒有開放給第三方串接的網站，用這招最省事，效果也最乾淨。
只拔除高風險端點不會動到其餘公開讀取
另一種力度靠 rest_endpoints 這個 filter。官方參考頁面說明，它過濾的是目前可用的 REST API 端點清單這個陣列，可以把 /wp/v2/users 與帶使用者 ID 的單一使用者路由從清單拿掉，其他端點像文章、頁面、分類這些本來就公開的內容，完全不受影響，照常運作。
這裡有一個條件一定要加，只在訪客沒有登入時才拿掉，也就是先用 is_user_logged_in() 判斷。區塊編輯器右側的文章作者下拉選單，就是呼叫 /wp/v2/users?who=authors 列出可選的作者，如果對所有人一律拔掉這支端點，已登入的編輯者、管理員也會跟著讀不到，作者選單就會壞掉。
代價是需要對自己網站實際在用哪些端點有點掌握，不像全站要求登入那樣一刀切、不用多想。拔除端點前，建議先確認網站有沒有功能依賴這個端點，有些會員外掛、社群登入外掛也可能會查詢使用者資訊，如果沒先確認就直接拔，可能某個功能默默壞掉了都不知道。這不是懶人包等級的設定，需要逐一判斷，但換來的是只處理真正的風險、其餘都不動。
站台有沒有對外功能，決定限制存取的力度
前面兩種做法哪個適合你，判準不是網站規模或流量，是有沒有設計成不需要登入就能透過 REST API 互動的功能。
純內容型、形象展示型的站台，沒有會員系統、沒有電商結帳、也沒有對外開放 API 給第三方 App，適合直接用全站要求登入的做法，效果最徹底，設定也最省事。有電商結帳、會員或訂閱系統、headless 前端，或是開放 API 給自己開發的 App、第三方系統串接的站台，應該改用精準拔除端點的做法，只對未登入的訪客拿掉真正高風險的 /wp/v2/users，其餘端點維持原樣，才不會把自己的對外功能一起關掉。
市面上常見的「停用 REST API」外掛，名字寫停用，實際做法多半是擋掉所有未登入訪客的請求，力度等同上面的全站要求登入，免登入表單、訪客結帳與 headless 前端一樣會被擋到。裝這類外掛之前，一樣要先做過上面這個判斷，你的網站有沒有依賴 REST API 的對外功能，不能因為它包裝成一個外掛，就跳過這一步。
設定生效後，要驗證風險有沒有擋住、功能有沒有被誤傷
改完設定不代表結束，兩件事都要親自驗證一次，不要設完就假設它生效了。
第一件事是確認風險真的被擋掉。用瀏覽器或無痕視窗，直接打開自己網站的 /wp-json/wp/v2/users，用全站要求登入的做法，應該看到 401 未授權錯誤；用拔除端點的做法，會看到找不到路由的 404 錯誤（rest_no_route），而不是一串使用者名稱與 ID。這個端點預設會列出使用者資訊，擋掉之後理應回傳拒絕，如果還看得到名單，代表設定沒生效，要回頭檢查 filter 有沒有正確掛上。
第二件事是確認沒有誤傷其他功能。後台能不能正常發文、正常編輯，先自己跑一次，用拔除端點做法的站台，也要打開區塊編輯器確認文章作者下拉選單還列得出作者；如果站上有免登入表單或結帳流程，也要實際走一遍，確認訪客端能不能正常送出。改完就假設沒事是最常見的失誤，前面提過，編輯器出問題常常只是「存檔沒反應」這種不容易聯想到 REST API 的症狀，只有實際跑過一次，才知道設定有沒有連帶擋掉不該擋的東西。
REST API 要不要限制，從來不是「關掉比較安全」這麼簡單的選擇題。已發布的內容本來就設計成公開，真正該收起來的只有 /wp/v2/users 這一小塊使用者資訊，而官方也早就把答案講得很清楚，用 filter 限制存取，而不是把整組功能關掉。挑對力度、改完親自驗證一次，網站才能在擋住真正的風險與保留原本該有的功能之間，站在剛好的位置上。