Por que o WordPress retorna 'Você não tem permissão de upload' para meu aplicativo de iPhone?

O endpoint da REST API /wp-json/wp/v2/media exige que o usuário do WordPress tenha a capability upload_files. Os papéis Subscriber (Assinante) e Contributor (Colaborador) não a possuem. Se seu aplicativo de iPhone se autentica como um usuário em um desses papéis, toda tentativa de upload retorna HTTP 403 com rest_cannot_create como código de erro. Promover o usuário a Author (Autor), ou a qualquer papel que inclua upload_files, resolve o problema.

Sou o administrador do site e ainda recebo 'sem permissão de upload'. O que está acontecendo?

Quando o papel do usuário está correto, a próxima causa provável é um plugin de segurança ou regra de WAF que bloqueia a REST API. Wordfence, iThemes Security, Solid Security e plugins do tipo 'Disable REST API' têm configurações que podem rejeitar tráfego REST não originado de um navegador. Regras de WAF do Cloudflare direcionadas a /wp-json/ têm o mesmo efeito. Use o log de eventos do seu firewall para identificar a regra específica de bloqueio e, em seguida, isente apenas essa regra para /wp-json/wp/v2/media.

A Application Password do WordPress concede o mesmo papel do usuário a que pertence?

Sim. Application Passwords são emitidas por usuário, e qualquer requisição autenticada com uma delas é executada como aquele usuário, com exatamente as capabilities dele. Se o usuário subjacente é um Subscriber, a Application Password não consegue fazer upload, mesmo que tenha sido gerada com sucesso. Application Passwords não têm expiração embutida; permanecem válidas até serem revogadas manualmente.

Como confirmo a capability upload_files a partir de um terminal?

Execute curl com -u username:application-password e envie um POST para /wp-json/wp/v2/media com uma pequena imagem de teste. HTTP 201 com um corpo JSON contendo o novo ID de mídia significa que os uploads funcionam. HTTP 403 com código rest_cannot_create significa que o papel não possui upload_files. HTTP 401 com rest_invalid_authentication significa que a Application Password está incorreta ou foi revogada. HTTP 403 com corpo de resposta que não vem do WordPress (página HTML de erro, desafio do Cloudflare) significa que um filtro upstream está bloqueando a requisição antes de o WordPress vê-la.

Devo simplesmente promover o usuário a Administrator?

Apenas como último recurso e somente para sites sob seu controle total. O princípio do menor privilégio diz que você deve dar ao usuário o menor papel que conceda upload_files, que é Author. Reserve Administrator para contas que realmente precisam gerenciar configurações, plugins ou outros usuários. Um papel personalizado dedicado, contendo apenas upload_files mais as capabilities mínimas de publicação, é ainda mais seguro para sites multiusuário.

Erro "Você não tem permissão de upload" no WordPress: como corrigir

TL;DR: O erro vem do seu servidor WordPress, não do aplicativo de iPhone, navegador ou script que faz a requisição. As duas causas mais comuns são: (1) o usuário associado à sua Application Password não tem a capability upload_files, ou (2) um plugin de segurança ou WAF está bloqueando /wp-json/wp/v2/media antes de o WordPress avaliar a requisição. Promova o usuário a Author (ou a qualquer papel que inclua upload_files), ou isente o endpoint de mídia da regra de firewall problemática, e os uploads passam a funcionar imediatamente.

Verificado contra o WordPress 6.7 em 2 de junho de 2026.

Diagnóstico rápido: o que a resposta te diz

Antes de alterar qualquer coisa, observe a resposta HTTP que seu cliente recebe. Cada combinação de código de status e corpo de erro aponta para uma causa raiz diferente.

Status HTTP	Código de erro	Causa provável	Primeiro passo
403	`rest_cannot_create`	Papel do usuário sem `upload_files`	Mudar o papel para Author ou superior (ver Causa Raiz 1)
401	`rest_invalid_authentication`	Application Password incorreta ou revogada	Regenerar a Application Password (ver Causa Raiz 4)
403	Página HTML, sem JSON	Plugin de segurança ou WAF bloqueou a requisição	Verificar o log de eventos do Wordfence / iThemes / Cloudflare
503 / timeout	(sem corpo)	WAF ou rate limiter derrubou a conexão	Inspecionar os logs do Cloudflare ou do firewall de origem
200	Página HTML, não JSON	REST API do WP desativada por plugin	Desativar o plugin "Disable REST API" ou equivalente

Como o erro chega de fato ao seu cliente

Quando um cliente envia uma foto para o WordPress, ele faz uma requisição POST para /wp-json/wp/v2/media. A requisição leva um cabeçalho Authorization com seu nome de usuário e uma Application Password — um token gerado em Usuários -> Perfil -> Application Passwords, um recurso nativo do WordPress desde a versão 5.6 (guia oficial de integração).

O core do WordPress então executa uma verificação de permissão antes de aceitar o arquivo. A lógica relevante em 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() )
    );
}

Se o usuário por trás da Application Password não tiver a capability upload_files, o WordPress retorna HTTP 403 com um corpo JSON contendo "code": "rest_cannot_create". Seu cliente recebe essa resposta e a exibe como "Você não tem permissão de upload".

Isso significa que a mensagem é literal: o WordPress está te dizendo que o usuário não tem permissão para fazer upload. O próximo passo é descobrir por quê. A lista completa de capabilities por papel está documentada na página oficial de Roles e Capabilities do WordPress.

Causa Raiz 1: o papel do usuário não tem upload_files

Esta é a causa mais frequente que observamos em casos de suporte do SnapPress. O WordPress tem cinco papéis padrão, e apenas alguns deles podem enviar mídia:

Papel	Pode enviar mídia?
Administrator	Sim
Editor	Sim
Author	Sim
Contributor	Não
Subscriber	Não

Se sua Application Password pertencer a um Contributor ou Subscriber, toda tentativa de upload falhará com o erro de permissão, mesmo que a autenticação tenha sucesso (a senha em si é válida; ela apenas não dá acesso suficiente).

Como verificar o papel

Faça login no admin do WordPress em https://your-site.example/wp-admin/.
Abra Usuários -> Todos os Usuários.
Encontre o usuário cuja Application Password você colocou no aplicativo cliente.
Observe a coluna Função (Role).

Se o papel for Contributor, Subscriber ou qualquer papel personalizado que não inclua upload_files, esse é o seu problema.

Como corrigir (menor privilégio primeiro)

A correção mais segura é promover o usuário a Author. Author é o papel padrão mínimo que inclui upload_files, além da capacidade de criar e publicar os próprios posts do usuário. Ele não pode gerenciar outros usuários, plugins ou configurações, e por isso é a escolha recomendada quando apenas o fluxo de upload é necessário.

Promova a Editor se o usuário também precisar editar e publicar posts de outros autores, ou a Administrator apenas quando o usuário realmente precisar de controle total do site (por exemplo, um site de proprietário único que você mesmo gerencia). Após mudar o papel, gere uma nova Application Password sob o usuário agora correto e atualize o aplicativo cliente. A nova senha é recomendada, mas não estritamente obrigatória; ela elimina a hipótese de "credencial desatualizada".

E se o papel for personalizado?

Se seu site usa um plugin de papéis como Members ou User Role Editor, o papel nomeado pode não corresponder aos padrões. Abra o editor de papéis, encontre o papel atribuído ao seu usuário e confirme que a caixa upload_files está marcada. Salve e tente novamente. Papéis personalizados também são onde a maioria das regressões de permissão se esconde; se os uploads funcionavam e pararam silenciosamente após uma atualização de plugin, este é o lugar para começar. Para sites multiusuário, a abordagem mais limpa é um papel personalizado dedicado, com upload_files mais as capabilities mínimas de publicação que você realmente precisa.

Causa Raiz 2: um plugin de segurança está bloqueando a REST API

Se o papel do seu usuário já inclui upload_files e os uploads ainda falham, o próximo suspeito é um plugin de segurança interceptando a requisição da REST API antes que o core do WordPress a veja. Suspeitos comuns:

Wordfence — regras de firewall podem combinar com cabeçalhos Authorization incomuns; o Rate Limiting pode estrangular tráfego REST.
iThemes Security / Solid Security — opções de hardening da REST API podem bloquear /wp-json/wp/v2/* para qualquer coisa que não seja uma sessão de navegador logado.
Disable REST API — o plugin literalmente chamado assim bloqueia todos os endpoints REST por padrão; é preciso colocar /wp/v2/media em whitelist para que uploads de aplicativos funcionem.
SecuPress, Shield Security e plugins similares têm configurações equivalentes.

Quando um desses bloqueia a requisição, o cliente vê o mesmo sintoma de "sem permissão de upload" porque o plugin devolve um 403 parecido com o erro nativo do WordPress. A diferença é que a verificação current_user_can() do core nunca é executada.

Especificidades do Wordfence

Duas configurações merecem ser verificadas. Abra Wordfence -> All Options -> Firewall Options:

Brute Force Protection: configurações agressivas de lockout podem banir uma Application Password após uma única tentativa.
Rate Limiting: os limites em "If anyone's requests exceed..." também se aplicam ao tráfego REST. Um aplicativo móvel tentando reenviar uploads que falharam pode disparar essas regras.

Se você suspeita do Wordfence, abra Wordfence -> Tools -> Live Traffic e dispare um upload pelo cliente. Se a requisição for bloqueada, o motivo aparece na entrada de log com a regra que disparou. A referência completa do firewall está em wordfence.com/help/firewall/.

Especificidades do iThemes Security / Solid Security

O Solid Security mudou o hardening da REST API entre releases. Em versões recentes, procure em Security -> Settings -> Advanced -> WordPress Tweaks pela opção da REST API (builds mais antigos a colocavam em Tools). Os dois estados que importam são:

Default (REST API enabled) — o que os uploads de aplicativos precisam.
Restricted — limita endpoints REST a sessões de navegador logado; requisições com Application Password podem falhar aqui.

Mude para Default se possível, ou coloque /wp/v2/media em whitelist explicitamente. O rótulo exato pode variar conforme a versão; consulte a documentação do Solid Security da sua versão.

Como diagnosticar

Desative os plugins suspeitos, um de cada vez, e tente o upload entre cada um. O plugin cuja desativação faz os uploads funcionarem é o culpado. Uma vez identificado, encontre a configuração específica que bloqueia a REST API e isente /wp-json/wp/v2/media dela. Todos os plugins da lista acima suportam alguma forma de isenção por endpoint, embora os caminhos de menu variem por versão.

Causa Raiz 3: um WAF está bloqueando a requisição

Se seu site está atrás de um web application firewall (Cloudflare WAF, Sucuri, AWS WAF, BunkerWeb), o WAF pode rejeitar a requisição de upload antes mesmo de ela chegar ao seu servidor WordPress. O Cloudflare em particular tem regras gerenciadas de WAF que visam corpos POST multipart grandes e combinações incomuns de Content-Type, ambos usados por um upload de mídia. Consulte a documentação do Cloudflare WAF para o catálogo de regras.

Os sintomas variam, mas tipicamente você obtém um destes:

HTTP 403 com uma página de erro do Cloudflare no corpo da resposta.
HTTP 503 ou timeout, sem nenhum corpo de erro.
HTTP 200 com uma resposta HTML em vez de JSON.

Correção estreita específica do Cloudflare

Não desative em massa as regras gerenciadas do Cloudflare. Em vez disso, identifique a regra específica que disparou:

Abra o painel do Cloudflare e vá em Security -> Events (anteriormente Firewall Events).
Dispare um upload com falha pelo seu cliente.
Filtre os eventos por host ou pela URI /wp-json/wp/v2/media. A regra de bloqueio aparece com seu ruleset ID e rule ID.
Crie uma regra personalizada em Security -> WAF -> Custom Rules que pule apenas aquela regra gerenciada específica para o endpoint de upload:

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

Defina a ação da regra como "Skip", direcionada ao ruleset / regra específica que você identificou, e não a todos os desafios gerenciados. Coloque a regra acima de qualquer regra "Block" na prioridade. Isso mantém a proteção ativa para o resto de /wp-json/, permitindo que uploads legítimos de mídia passem.

Causa Raiz 4: falha de autenticação ou Application Password revogada

Application Passwords não têm expiração embutida; uma vez emitidas, permanecem válidas até serem revogadas manualmente. Por isso, o sintoma aqui costuma ser HTTP 401 com rest_invalid_authentication, e não o 403 de permissão. Mas vale verificar quando nada mais se encaixa:

Abra o admin do WordPress -> Usuários -> Perfil -> Application Passwords.
Confirme que a senha que você registrou no aplicativo cliente ainda está listada.
Se ela foi removida (manualmente, por um plugin de segurança ou por um evento de troca de senha), gere uma nova e atualize o cliente.
Confirme que seu site é acessível por HTTPS. O WordPress remove o cabeçalho Authorization em HTTP puro por segurança; uma incompatibilidade http-para-https pode produzir 401s intermitentes.
Confirme que nenhum plugin de segurança ou código personalizado desativou Application Passwords via o filtro wp_is_application_passwords_available.

Alguns plugins de segurança revogam automaticamente Application Passwords em determinados eventos (trocas de senha, mudanças de papel, atividade suspeita). Se seu papel foi alterado recentemente, só isso já pode ter revogado as senhas existentes. Regenerar é uma correção de um minuto.

Confirmando a correção pela linha de comando

Após aplicar uma correção, você pode verificar se os uploads funcionam sem envolver o aplicativo cliente. De qualquer máquina com curl, execute:

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

Um upload bem-sucedido retorna HTTP 201 e um corpo JSON que inclui o id, source_url e media_details do novo item de mídia. Qualquer outra coisa aponta de volta para a tabela de diagnóstico no topo deste artigo, e o corpo da resposta geralmente te diz qual linha se aplica.

Se você não puder executar curl, o mesmo teste pode ser feito a partir do Postman ou de qualquer cliente HTTP que suporte autenticação Basic e dados de formulário multipart. O endpoint, as credenciais e a resposta esperada são idênticos.

Por que um aplicativo móvel não pode resolver isso por você

É tentador supor que um bug de upload deve estar no aplicativo, porque o aplicativo é a parte visível da cadeia. Mas a REST API do WordPress é a guardiã autoritativa do que qualquer cliente (navegador, aplicativo iOS, Zapier, linha de comando) pode fazer. O trabalho do aplicativo é enviar uma requisição bem formada com credenciais válidas e mostrar a resposta. Se o WordPress diz "sem permissão de upload", mudar o aplicativo não muda a resposta. A correção precisa acontecer do lado do WordPress: papel, configurações de plugin, regras de WAF ou Application Password.

Isso é por design e é uma força do modelo da REST API. As mesmas verificações protegem seu site quer alguém use um aplicativo de celular, um cliente desktop ou escreva um script personalizado.

Checklist de resumo

Leia o código de status HTTP e o código de erro da resposta real. Compare com a tabela de diagnóstico no topo.
Verifique o papel do usuário do WordPress. Ele precisa incluir upload_files (Author ou superior entre os papéis padrão).
Se o papel estiver correto, desative plugins de segurança um de cada vez e tente os uploads novamente.
Se nenhum plugin for a causa, verifique o log de eventos do seu WAF; adicione uma exceção de regra estreita para /wp-json/wp/v2/media somente para a regra específica que disparou.
Confirme que a Application Password ainda está listada no perfil do usuário e que seu site está em HTTPS; regenere se necessário.
Verifique de ponta a ponta com curl antes de voltar ao aplicativo cliente.

Seguir essa ordem resolve a maioria dos relatos de "sem permissão de upload" que vemos vindos de usuários do SnapPress. A mensagem de erro está fazendo seu trabalho; ela só precisa do contexto certo para agir.

Perguntas frequentes

Por que o WordPress retorna 'Você não tem permissão de upload' para meu aplicativo de iPhone?: O endpoint da REST API /wp-json/wp/v2/media exige que o usuário do WordPress tenha a capability upload_files. Os papéis Subscriber e Contributor não a possuem. Se seu aplicativo de iPhone se autentica como um usuário em um desses papéis, toda tentativa de upload retorna HTTP 403 com rest_cannot_create como código de erro. Promover o usuário a Author (ou a qualquer papel que inclua upload_files) resolve o problema.
Sou o administrador do site e ainda recebo 'sem permissão de upload'. O que está acontecendo?: Quando o papel do usuário está correto, a próxima causa provável é um plugin de segurança ou regra de WAF que bloqueia a REST API. Wordfence, iThemes Security, Solid Security e plugins "Disable REST API" têm configurações que podem rejeitar tráfego REST não originado de um navegador. Regras de WAF do Cloudflare direcionadas a /wp-json/ têm o mesmo efeito. Use o log de eventos do seu firewall para identificar a regra específica de bloqueio e, em seguida, isente apenas essa regra para /wp-json/wp/v2/media.
A Application Password do WordPress concede o mesmo papel do usuário a que pertence?: Sim. Application Passwords são emitidas por usuário, e qualquer requisição autenticada com uma delas é executada como aquele usuário, com exatamente as capabilities dele. Se o usuário subjacente é um Subscriber, a Application Password não consegue fazer upload, mesmo que tenha sido gerada com sucesso. Application Passwords não têm expiração embutida; permanecem válidas até serem revogadas manualmente.
Como confirmo a capability upload_files a partir de um terminal?: Execute curl com -u username:application-password e envie um POST para /wp-json/wp/v2/media com uma pequena imagem de teste. HTTP 201 com um corpo JSON contendo o novo ID de mídia significa que os uploads funcionam. HTTP 403 com código rest_cannot_create significa que o papel não possui upload_files. HTTP 401 com rest_invalid_authentication significa que a Application Password está incorreta ou foi revogada. HTTP 403 com corpo de resposta que não vem do WordPress (página HTML de erro, desafio do Cloudflare) significa que um filtro upstream está bloqueando a requisição antes de o WordPress vê-la.
Devo simplesmente promover o usuário a Administrator?: Apenas como último recurso e somente para sites sob seu controle total. O princípio do menor privilégio diz que você deve dar ao usuário o menor papel que conceda upload_files, que é Author. Reserve Administrator para contas que realmente precisam gerenciar configurações, plugins ou outros usuários. Um papel personalizado dedicado, contendo apenas upload_files mais as capabilities de publicação, é ainda mais seguro para sites multiusuário.