為什麼 WordPress 對我的 iPhone App 回傳「You do not have upload permission」？

REST API 端點 /wp-json/wp/v2/media 要求 WordPress 使用者具備 upload_files 權限。Subscriber 與 Contributor 角色不具備此權限。如果你的 iPhone App 以這兩種角色之一進行驗證，每次上傳嘗試都會回傳 HTTP 403，錯誤代碼為 rest_cannot_create。將該使用者提升為 Author（或任何包含 upload_files 的角色）即可解決。

我已經是網站管理員，仍然出現「no upload permission」。發生什麼事？

當使用者角色正確時，下一個可能原因是安全外掛或 WAF 規則阻擋了 REST API。Wordfence、iThemes Security、Solid Security 及「Disable REST API」這類外掛都有可能拒絕非瀏覽器的 REST 流量。鎖定 /wp-json/ 的 Cloudflare WAF 規則也會造成相同效果。請利用防火牆的事件記錄找出特定的阻擋規則，再僅針對 /wp-json/wp/v2/media 解除該規則。

WordPress Application Password 是否會繼承所屬使用者的角色？

是的。Application Password 是針對個別使用者發行的，使用該密碼驗證的請求會以該使用者的身分與權限執行。如果底層使用者是 Subscriber，即使 Application Password 成功產生，也無法上傳。Application Password 沒有內建到期時間，除非手動撤銷，否則會一直有效。

如何從終端機確認 upload_files 權限？

使用 curl 加上 -u username:application-password 並對 /wp-json/wp/v2/media POST 一張小測試圖片。如果回傳 HTTP 201 且 JSON body 包含新的 media ID，表示上傳可正常運作。HTTP 403 並回傳 rest_cannot_create 表示該角色缺少 upload_files。HTTP 401 並回傳 rest_invalid_authentication 表示 Application Password 錯誤或已被撤銷。如果 HTTP 403 的回應 body 並非 WordPress 格式（HTML 錯誤頁、Cloudflare 挑戰），表示上游過濾器在 WordPress 看到請求前就阻擋了它。

是不是直接把使用者提升為 Administrator 就好？

僅作為最後手段，並且只在你完全掌控的網站上使用。根據最小權限原則，應將使用者賦予能授予 upload_files 的最小角色，也就是 Author。Administrator 應保留給真正需要管理設定、外掛或其他使用者的帳號。對多人共用的網站而言，建立僅含 upload_files 與最低必要發文權限的專屬自訂角色會更安全。

WordPress「You Do Not Have Upload Permission」錯誤：如何修復

TL;DR：此錯誤來自你的 WordPress 伺服器，而非發送請求的 iPhone App、瀏覽器或腳本。最常見的兩個原因是：(1) 你的 Application Password 所屬使用者缺少 upload_files 權限；或 (2) 安全外掛或 WAF 在 WordPress 處理請求之前就阻擋了 /wp-json/wp/v2/media。將該使用者提升為 Author（或任何包含 upload_files 的角色），或讓媒體端點不受該防火牆規則限制，上傳就會立刻恢復運作。

本文已於 2026 年 6 月 2 日針對 WordPress 6.7 完成驗證。

快速診斷：回應內容告訴你什麼

在進行任何變更前，先檢視你的用戶端收到的 HTTP 回應。狀態碼與錯誤內容的不同組合，對應到不同的根本原因。

HTTP 狀態碼	錯誤代碼	可能原因	第一步處理
403	`rest_cannot_create`	使用者角色缺少 `upload_files`	將角色改為 Author 或更高（見根本原因 1）
401	`rest_invalid_authentication`	Application Password 錯誤或被撤銷	重新產生 Application Password（見根本原因 4）
403	HTML 頁面、無 JSON	安全外掛或 WAF 阻擋了請求	檢查 Wordfence／iThemes／Cloudflare 事件記錄
503／逾時	（無 body）	WAF 或速率限制中斷了連線	檢視 Cloudflare 或源站防火牆紀錄
200	HTML 頁面、非 JSON	WP REST API 被外掛停用	停用「Disable REST API」或同類外掛

錯誤實際上是如何抵達用戶端的

當用戶端要將照片上傳到 WordPress 時，會對 /wp-json/wp/v2/media 發送 POST 請求。該請求帶有 Authorization 標頭，內含你的使用者名稱與 Application Password — 這是你在 使用者 -> 個人資料 -> Application Passwords 產生的權杖，是 WordPress 自 5.6 版起的核心功能（官方整合指南）。

WordPress 核心會在接受檔案之前先執行權限檢查。WP_REST_Attachments_Controller::create_item_permissions_check() 中的相關邏輯如下：

if ( ! current_user_can( 'upload_files' ) ) {
    return new WP_Error(
        'rest_cannot_create',
        __( 'Sorry, you are not allowed to upload media on this site.' ),
        array( 'status' => rest_authorization_required_code() )
    );
}

若 Application Password 所屬使用者不具備 upload_files 權限，WordPress 會回傳 HTTP 403，JSON body 含有 "code": "rest_cannot_create"。你的用戶端收到此回應後，便顯示為「You do not have upload permission」。

也就是說這個訊息是字面意義：WordPress 在告訴你該使用者不被允許上傳。下一步是釐清為什麼。完整的角色權限清單可參考 WordPress 官方 Roles and Capabilities 文件。

根本原因 1：使用者角色缺少 upload_files

這是我們在 SnapPress 支援案件中最常看到的原因。WordPress 有五種預設角色，其中只有部分能上傳媒體：

角色	可上傳媒體？
Administrator	可以
Editor	可以
Author	可以
Contributor	不行
Subscriber	不行

如果你的 Application Password 屬於 Contributor 或 Subscriber，即使驗證成功，每次上傳嘗試都會因權限錯誤而失敗（密碼本身有效，只是換不到足夠的存取權）。

如何檢查角色

登入你的 WordPress 後台：https://your-site.example/wp-admin/。
開啟 使用者 -> 全部使用者。
找到你將 Application Password 設定到用戶端 App 中所屬的那位使用者。
檢視角色欄。

若角色為 Contributor、Subscriber，或任何不含 upload_files 的自訂角色，問題就在這裡。

修復方式（從最小權限開始）

最安全的方式是將該使用者提升為 Author。Author 是預設角色中包含 upload_files 的最低角色，並可建立與發布自己的文章。它無法管理其他使用者、外掛或設定，因此在僅需上傳工作流程的情境下是建議選擇。

若該使用者還需編輯與發布其他作者的文章，請提升為 Editor；只有在使用者確實需要完整網站控制權時（例如你自己管理的單人網站）才提升為 Administrator。更改角色後，在新角色下重新產生一組 Application Password 並更新用戶端 App。重新產生並非絕對必要，但有助於排除「舊憑證」這個假設。

如果是自訂角色？

若你的網站使用 Members 或 User Role Editor 等角色外掛，名稱相同的角色未必對應到預設角色的權限。請在角色編輯介面找到該使用者所屬的角色，確認 upload_files 已被勾選後存檔再試。自訂角色也是大多數權限回歸問題隱藏的地方；若以往能上傳卻在某次外掛更新後悄悄失效，這就是優先排查之處。對多使用者網站而言，最乾淨的作法是建立一個只含 upload_files 加上你實際需要的最低發文權限的專屬自訂角色。

根本原因 2：安全外掛阻擋了 REST API

如果你的使用者角色已含 upload_files，上傳仍然失敗，下一個嫌疑就是安全外掛在 WordPress 核心處理請求之前先攔截了它。常見的問題來源：

Wordfence：防火牆規則可能比對到不尋常的 Authorization 標頭；Rate Limiting 也可能限制 REST 流量。
iThemes Security／Solid Security：REST API 強化選項可能讓 /wp-json/wp/v2/* 僅接受已登入瀏覽器 Session 的請求。
Disable REST API：這個外掛字面上就會預設停用所有 REST 端點；你必須將 /wp/v2/media 加入白名單，App 上傳才會運作。
SecuPress、Shield Security等類似外掛都有對應設定。

當其中之一阻擋了請求時，用戶端會看到相同的「no upload permission」症狀，因為這些外掛會回傳一個類似 WordPress 自身錯誤的 403。差別在於核心的 current_user_can() 檢查從未被執行。

Wordfence 的具體設定

有兩個設定值得檢查。打開 Wordfence -> All Options -> Firewall Options：

Brute Force Protection：過於嚴格的封鎖設定可能在一次重試後就封鎖 Application Password。
Rate Limiting：「If anyone's requests exceed...」的門檻同樣適用於 REST 流量。手機 App 重試失敗上傳時可能觸發。

如果你懷疑是 Wordfence，請打開 Wordfence -> Tools -> Live Traffic，再從用戶端觸發一次上傳。若請求被阻擋，記錄中會顯示觸發的規則與原因。完整防火牆說明可參考 wordfence.com/help/firewall/。

iThemes Security／Solid Security 的具體設定

Solid Security 的 REST API 強化選項在不同版本之間搬過位置。在較新的版本中，請至 Security -> Settings -> Advanced -> WordPress Tweaks 尋找 REST API 選項（舊版可能位於 Tools）。需要關注的兩種狀態：

Default（REST API enabled）：App 上傳所需的狀態。
Restricted：將 REST 端點限制為已登入瀏覽器 Session；Application Password 請求可能因此失敗。

能切換到 Default 就切換，或將 /wp/v2/media 明確加入白名單。實際的選項標示可能因版本而異；請依照你使用的版本參閱 Solid Security 文件。

診斷方式

逐一停用可疑外掛，並在每次停用後重新嘗試上傳。停用後能讓上傳成功的外掛就是元兇。鎖定後，找出阻擋 REST API 的特定設定，並僅針對 /wp-json/wp/v2/media 設定例外。上述清單中的外掛都支援某種形式的端點層級例外，只是選單路徑因版本而異。

根本原因 3：WAF 阻擋了請求

如果你的網站位於 Web 應用程式防火牆（Cloudflare WAF、Sucuri、AWS WAF、BunkerWeb）後方，WAF 可能在請求抵達 WordPress 伺服器之前就拒絕該上傳請求。Cloudflare 特別有針對大型 multipart POST body 與不尋常 Content-Type 組合的 WAF 受管規則，而媒體上傳這兩者都會用到。可參考 Cloudflare 的 WAF 文件取得規則目錄。

症狀各有不同，但通常會出現以下其中之一：

HTTP 403，回應 body 為 Cloudflare 錯誤頁。
HTTP 503 或逾時，完全沒有錯誤 body。
HTTP 200，但回應為 HTML 而非 JSON。

Cloudflare 專屬的窄範圍修復

請勿大規模停用 Cloudflare 受管規則。應改為找出實際觸發的特定規則：

打開 Cloudflare 儀表板，前往 Security -> Events（原稱 Firewall Events）。
從用戶端觸發一次失敗的上傳。
依主機或 URI /wp-json/wp/v2/media 過濾事件。被阻擋的規則會顯示其 ruleset ID 與 rule ID。
在 Security -> WAF -> Custom Rules 建立自訂規則，僅針對該上傳端點略過你所識別到的特定受管規則：

(http.request.uri.path eq "/wp-json/wp/v2/media") and (http.request.method eq "POST")

將規則動作設為 "Skip"，目標限定在你識別到的特定 ruleset／rule，而非所有受管挑戰。將該規則的優先順序放在任何「Block」規則之上。如此既能對 /wp-json/ 的其餘部分維持防護，同時讓合法的媒體上傳通過。

根本原因 4：驗證失敗或 Application Password 已被撤銷

Application Password 沒有內建到期時間；一旦發出，除非手動撤銷否則持續有效。因此這裡的症狀通常是 HTTP 401 並回傳 rest_invalid_authentication，而非 403 權限錯誤。但在其他項目都不符時值得確認：

進入 WordPress 後台 -> 使用者 -> 個人資料 -> Application Passwords。
確認你在用戶端 App 中註冊的那組密碼仍列在清單上。
若已被移除（手動、由安全外掛、或因密碼變更事件），請產生新密碼並更新用戶端。
確認你的網站可透過 HTTPS 連線。WordPress 在純 HTTP 環境下會基於安全考量移除 Authorization 標頭；http 與 https 不一致可能造成偶發 401。
確認沒有任何安全外掛或自訂程式碼透過 wp_is_application_passwords_available 篩選器停用了 Application Passwords。

某些安全外掛會在特定事件（變更密碼、變更角色、可疑活動）時自動撤銷 Application Passwords。如果你的角色最近被變更過，光是這個動作就可能已撤銷現有密碼。重新產生只需要一分鐘。

從命令列確認修復成果

套用修復後，你可以在完全不動用用戶端 App 的情況下驗證上傳功能。在任一具備 curl 的機器上執行：

curl -u 'your-username:your-application-password' \
  -X POST \
  -H 'Content-Disposition: attachment; filename=test.jpg' \
  -H 'Content-Type: image/jpeg' \
  --data-binary @test.jpg \
  https://your-site.example/wp-json/wp/v2/media

上傳成功時會回傳 HTTP 201，並有 JSON body 包含新媒體項目的 id、source_url 與 media_details。其他結果都應回到本文最上方的診斷表，回應 body 通常會直接指出對應的列。

若無法使用 curl，同樣的測試可在 Postman 或任何支援 Basic 驗證與 multipart form data 的 HTTP 用戶端執行。端點、憑證與預期回應完全相同。

為何手機 App 無法為你解決這件事

很容易誤以為上傳問題一定出在 App，因為 App 是整條鏈中最可見的部分。但 WordPress REST API 才是任何用戶端（瀏覽器、iOS App、Zapier、命令列）能做什麼的權威守門人。App 的職責是發出格式正確且帶有效憑證的請求，並呈現回應。如果 WordPress 回答「no upload permission」，更換 App 並不會讓答案改變。修復必須發生在 WordPress 那一側：角色、外掛設定、WAF 規則，或 Application Password。

這是 REST API 模型刻意的設計，也是它的優點。同樣的檢查會保護你的網站，不論對方使用手機 App、桌機用戶端，或是自行撰寫腳本。

總結檢查清單

讀取實際回應中的 HTTP 狀態碼與錯誤代碼。對照本文最上方的診斷表。
檢查 WordPress 使用者角色，必須包含 upload_files（預設角色中為 Author 或更高）。
若角色正確，逐一停用安全外掛並重試上傳。
若皆非外掛所致，檢視 WAF 事件記錄；僅針對實際觸發的規則，為 /wp-json/wp/v2/media 加入窄範圍例外。
確認 Application Password 仍列於使用者資料中，且網站使用 HTTPS；必要時重新產生。
在回到用戶端 App 之前，先以 curl 進行端到端驗證。

依此順序處理，可以解決我們在 SnapPress 使用者回報中大多數的「no upload permission」案件。錯誤訊息本身在盡職地告訴你問題；它只是需要正確的脈絡才能讓你採取對應動作。

常見問題

為什麼 WordPress 對我的 iPhone App 回傳「You do not have upload permission」？: REST API 端點 /wp-json/wp/v2/media 要求 WordPress 使用者具備 upload_files 權限。Subscriber 與 Contributor 角色不具備此權限。如果你的 iPhone App 以這兩種角色之一進行驗證，每次上傳嘗試都會回傳 HTTP 403，錯誤代碼為 rest_cannot_create。將該使用者提升為 Author（或任何包含 upload_files 的角色）即可解決。
我已經是網站管理員，仍然出現「no upload permission」。發生什麼事？: 當使用者角色正確時，下一個可能原因是安全外掛或 WAF 規則阻擋了 REST API。Wordfence、iThemes Security、Solid Security 以及「Disable REST API」這類外掛都有可能拒絕非瀏覽器的 REST 流量。鎖定 /wp-json/ 的 Cloudflare WAF 規則也會造成相同效果。請利用防火牆的事件記錄找出特定的阻擋規則，再僅針對 /wp-json/wp/v2/media 解除該規則。
WordPress Application Password 是否會繼承所屬使用者的角色？: 是的。Application Password 是針對個別使用者發行的，使用該密碼驗證的請求會以該使用者的身分與權限執行。如果底層使用者是 Subscriber，即使 Application Password 成功產生，也無法上傳。Application Password 沒有內建到期時間，除非手動撤銷，否則會一直有效。
如何從終端機確認 upload_files 權限？: 使用 curl 加上 -u username:application-password 並對 /wp-json/wp/v2/media POST 一張小測試圖片。若回傳 HTTP 201 且 JSON body 包含新的 media ID，表示上傳可正常運作。HTTP 403 並回傳 rest_cannot_create 表示該角色缺少 upload_files。HTTP 401 並回傳 rest_invalid_authentication 表示 Application Password 錯誤或已被撤銷。若 HTTP 403 的回應 body 並非 WordPress 格式（HTML 錯誤頁、Cloudflare 挑戰），表示上游過濾器在 WordPress 看到請求前就阻擋了它。
是不是直接把使用者提升為 Administrator 就好？: 僅作為最後手段，並且只在你完全掌控的網站上使用。根據最小權限原則，應將使用者賦予能授予 upload_files 的最小角色，也就是 Author。Administrator 應保留給真正需要管理設定、外掛或其他使用者的帳號。對多人共用的網站而言，建立僅含 upload_files 與最低必要發文權限的專屬自訂角色會更安全。