Errore WordPress "Non hai i permessi per caricare": come risolverlo

In breve: L'errore proviene dal tuo server WordPress, non dall'app per iPhone, dal browser o dallo script che effettua la richiesta. Le due cause più comuni sono: (1) l'utente dietro la tua Application Password non ha la capability upload_files, oppure (2) un plugin di sicurezza / WAF sta bloccando /wp-json/wp/v2/media prima che WordPress valuti la richiesta. Promuovi l'utente ad Autore (o a qualsiasi ruolo che includa upload_files), oppure esonera l'endpoint media dalla regola firewall responsabile, e i caricamenti funzioneranno immediatamente.

Verificato su WordPress 6.7 il 2 giugno 2026.

Diagnosi rapida: cosa ti dice la risposta

Prima di cambiare qualcosa, osserva la risposta HTTP che riceve il tuo client. Ogni combinazione di codice di stato e corpo di errore indica una causa diversa.

Stato HTTP	Codice errore	Causa probabile	Primo passo
403	rest_cannot_create	Il ruolo utente non ha upload_files	Cambia il ruolo in Autore o superiore (vedi Causa principale 1)
401	rest_invalid_authentication	Application Password errata o revocata	Rigenera l'Application Password (vedi Causa principale 4)
403	Pagina HTML, nessun JSON	Plugin di sicurezza o WAF ha bloccato la richiesta	Controlla il log eventi di Wordfence / iThemes / Cloudflare
503 / timeout	(nessun corpo)	WAF o rate limiter ha chiuso la connessione	Ispeziona i log di Cloudflare o del firewall di origine
200	Pagina HTML, non JSON	REST API di WP disattivata da un plugin	Disattiva "Disable REST API" o un plugin equivalente

Come l'errore raggiunge effettivamente il tuo client

Quando un client carica una foto su WordPress, effettua una richiesta POST a /wp-json/wp/v2/media. La richiesta porta un header Authorization con il tuo nome utente e una Application Password — un token che generi in Utenti -> Profilo -> Application Passwords, una funzionalità del core di WordPress dalla versione 5.6 (guida ufficiale all'integrazione).

Il core di WordPress esegue quindi un controllo dei permessi prima di accettare il file. La logica rilevante in 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 l'utente dietro l'Application Password non ha la capability upload_files, WordPress restituisce HTTP 403 con un corpo JSON contenente "code": "rest_cannot_create". Il tuo client riceve quella risposta e la mostra come "Non hai i permessi per caricare".

Questo significa che il messaggio è letterale: WordPress ti sta dicendo che l'utente non è autorizzato a caricare. Il passo successivo è capire perché. L'elenco completo delle capability per ruolo è documentato nella pagina ufficiale Roles and Capabilities di WordPress.

Causa principale 1: il ruolo utente non ha upload_files

Questa è la causa più frequente che osserviamo nei casi di supporto di SnapPress. WordPress ha cinque ruoli predefiniti, e solo alcuni di essi possono caricare media:

Ruolo	Può caricare media?
Amministratore	Sì
Editore	Sì
Autore	Sì
Collaboratore	No
Sottoscrittore	No

Se la tua Application Password appartiene a un Collaboratore o a un Sottoscrittore, ogni tentativo di caricamento fallirà con l'errore di permesso, anche se l'autenticazione riesce (la password in sé è valida; semplicemente non garantisce accesso sufficiente).

Come verificare il ruolo

1. Accedi al pannello di amministrazione di WordPress su https://your-site.example/wp-admin/.
2. Apri Utenti -> Tutti gli utenti.
3. Trova l'utente la cui Application Password hai inserito nell'app client.
4. Guarda la colonna Ruolo.

Se il ruolo è Collaboratore, Sottoscrittore o qualcosa di personalizzato che non include upload_files, quello è il tuo problema.

Come risolverlo (prima il minimo privilegio)

La soluzione più sicura è promuovere l'utente ad Autore. Autore è il ruolo predefinito minimo che include upload_files, oltre alla capacità di creare e pubblicare gli articoli dell'utente stesso. Non può gestire altri utenti, plugin o impostazioni, quindi è la scelta consigliata quando serve solo il flusso di caricamento.

Promuovi a Editore se l'utente deve anche modificare e pubblicare gli articoli di altri autori, oppure ad Amministratore solo quando l'utente ha realmente bisogno del pieno controllo del sito (ad esempio, un sito a singolo proprietario che gestisci personalmente). Dopo aver cambiato il ruolo, genera una nuova Application Password sotto l'utente ora corretto e aggiorna l'app client. La password fresca è consigliata ma non strettamente necessaria; elimina l'ipotesi della "credenziale obsoleta".

E se il ruolo è personalizzato?

Se il tuo sito usa un plugin di gestione ruoli come Members o User Role Editor, il ruolo nominato potrebbe non corrispondere a quelli predefiniti. Apri l'editor dei ruoli, trova il ruolo assegnato al tuo utente e conferma che la casella upload_files sia abilitata. Salva e riprova. I ruoli personalizzati sono anche il luogo in cui si nasconde la maggior parte delle regressioni dei permessi; se un sito un tempo funzionava e ha smesso silenziosamente di funzionare dopo un aggiornamento di un plugin, è da qui che bisogna iniziare. Per i siti multi-utente, l'approccio più pulito è un ruolo personalizzato dedicato con upload_files più le capability di pubblicazione minime di cui hai realmente bisogno.

Causa principale 2: un plugin di sicurezza sta bloccando la REST API

Se il ruolo del tuo utente include già upload_files e i caricamenti continuano a fallire, il sospetto successivo è un plugin di sicurezza che intercetta la richiesta REST API prima che il core di WordPress la veda. Colpevoli comuni:

• Wordfence — le regole firewall possono corrispondere a header Authorization insoliti; il Rate Limiting può limitare il traffico REST.
• iThemes Security / Solid Security — le opzioni di hardening della REST API possono bloccare /wp-json/wp/v2/* da tutto ciò che non sia una sessione browser autenticata.
• Disable REST API — il plugin chiamato letteralmente così blocca tutti gli endpoint REST per impostazione predefinita; devi mettere in whitelist /wp/v2/media per far funzionare i caricamenti delle app.
• SecuPress, Shield Security e plugin simili hanno impostazioni equivalenti.

Quando uno di questi blocca la richiesta, il client vede lo stesso sintomo di "nessun permesso di caricamento" perché il plugin restituisce un 403 che somiglia all'errore di WordPress stesso. La differenza è che il controllo current_user_can() del core non viene mai eseguito.

Specifiche di Wordfence

Vale la pena controllare due impostazioni. Apri Wordfence -> All Options -> Firewall Options:

• Brute Force Protection: impostazioni di lockout aggressive possono bandire un'Application Password dopo un singolo nuovo tentativo.
• Rate Limiting: le soglie per "If anyone's requests exceed..." si applicano anche al traffico REST. Un'app mobile che riprova caricamenti falliti può farle scattare.

Se sospetti Wordfence, apri Wordfence -> Tools -> Live Traffic e attiva un caricamento dal client. Se la richiesta viene bloccata, il motivo appare nella voce di log con la regola che è scattata. Il riferimento completo del firewall si trova su wordfence.com/help/firewall/.

Specifiche di iThemes Security / Solid Security

Solid Security ha spostato l'hardening della REST API tra le varie versioni. Nelle versioni recenti, cerca sotto Security -> Settings -> Advanced -> WordPress Tweaks per l'opzione REST API (le build più vecchie la collocavano sotto Tools). I due stati che ti interessano sono:

1. Default (REST API abilitata) — quello di cui hanno bisogno i caricamenti delle app.
2. Restricted — limita gli endpoint REST alle sessioni browser autenticate; le richieste con Application Password possono fallire qui.

Passa a Default se possibile, oppure metti esplicitamente in whitelist /wp/v2/media. L'etichetta esatta può variare in base alla versione; consulta la documentazione di Solid Security per la tua release.

Come diagnosticare

Disattiva i plugin sospetti uno alla volta e riprova il caricamento tra un test e l'altro. Il plugin la cui disattivazione fa riuscire i caricamenti è il colpevole. Una volta identificato, trova l'impostazione specifica che blocca la REST API ed esonera /wp-json/wp/v2/media. Ogni plugin nell'elenco sopra supporta in qualche forma un'esenzione per singolo endpoint, anche se i percorsi di menu variano in base alla versione.

Causa principale 3: un WAF sta bloccando la richiesta

Se il tuo sito si trova dietro un web application firewall (Cloudflare WAF, Sucuri, AWS WAF, BunkerWeb), il WAF può respingere la richiesta di caricamento prima che raggiunga il tuo server WordPress. Cloudflare in particolare ha regole gestite del WAF che mirano a corpi POST multipart di grandi dimensioni e a combinazioni insolite di Content-Type, entrambe utilizzate da un caricamento media. Vedi la documentazione WAF di Cloudflare per il catalogo delle regole.

I sintomi variano, ma in genere ottieni uno di questi:

• HTTP 403 con una pagina di errore Cloudflare nel corpo della risposta.
• HTTP 503 o un timeout, senza alcun corpo di errore.
• HTTP 200 con una risposta HTML invece di JSON.

Soluzione mirata specifica per Cloudflare

Non disattivare in blocco le regole gestite di Cloudflare. Invece, identifica la regola specifica che è scattata:

1. Apri la dashboard di Cloudflare e vai su Security -> Events (precedentemente Firewall Events).
2. Attiva un caricamento che fallisce dal tuo client.
3. Filtra gli eventi per host o per la URI /wp-json/wp/v2/media. La regola che blocca appare con il suo ruleset ID e rule ID.
4. Crea una regola personalizzata sotto Security -> WAF -> Custom Rules che salti solo quella specifica regola gestita per l'endpoint di caricamento:

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

Imposta l'azione della regola su "Skip" mirata al ruleset / regola specifica che hai identificato, non a tutti i managed challenge. Posiziona la regola sopra qualsiasi regola "Block" per priorità. Questo mantiene la protezione attiva per il resto di /wp-json/ permettendo allo stesso tempo il passaggio dei caricamenti media legittimi.

Causa principale 4: errore di autenticazione o Application Password revocata

Le Application Password non hanno una scadenza integrata; una volta emesse, rimangono valide finché non vengono revocate manualmente. Quindi il sintomo qui è di solito HTTP 401 con rest_invalid_authentication, non l'errore di permesso 403. Ma vale la pena controllare quando nient'altro corrisponde:

1. Apri admin di WordPress -> Utenti -> Profilo -> Application Passwords.
2. Conferma che la password che hai registrato nell'app client sia ancora elencata.
3. Se è stata rimossa (manualmente, da un plugin di sicurezza o da un evento di cambio password), generane una nuova e aggiorna il client.
4. Conferma che il tuo sito sia raggiungibile via HTTPS. WordPress rimuove l'header Authorization su HTTP semplice per motivi di sicurezza; una discrepanza http-to-https può produrre 401 intermittenti.
5. Conferma che nessun plugin di sicurezza o codice personalizzato abbia disabilitato le Application Password tramite il filtro wp_is_application_passwords_available.

Alcuni plugin di sicurezza revocano automaticamente le Application Password in determinati eventi (cambi di password, cambi di ruolo, attività sospette). Se il tuo ruolo è stato modificato di recente, questo da solo potrebbe aver revocato le password esistenti. La rigenerazione richiede un minuto.

Confermare la correzione dalla riga di comando

Una volta applicata una correzione, puoi verificare che i caricamenti funzionino senza coinvolgere affatto l'app client. Da qualsiasi macchina con curl, esegui:

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

Un caricamento riuscito restituisce HTTP 201 e un corpo JSON che include id, source_url e media_details del nuovo elemento media. Qualsiasi altra cosa riconduce alla tabella diagnostica all'inizio di questo articolo, e il corpo della risposta di solito ti dice quale riga si applica.

Se non puoi eseguire curl, lo stesso test può essere fatto da Postman o da qualsiasi client HTTP che supporti l'autenticazione Basic e i form multipart. L'endpoint, le credenziali e la risposta attesa sono identici.

Perché un'app mobile non può risolvere questo problema al posto tuo

È tentante presumere che un bug di caricamento debba essere nell'app, perché l'app è la parte visibile della catena. Ma la REST API di WordPress è il gatekeeper autorevole su ciò che qualsiasi client (browser, app iOS, Zapier, riga di comando) è autorizzato a fare. Il compito dell'app è inviare una richiesta ben formata con credenziali valide e mostrare la risposta. Se WordPress dice "nessun permesso di caricamento", cambiare l'app non può far cambiare la risposta. La correzione deve avvenire dal lato WordPress: ruolo, impostazioni dei plugin, regole WAF o Application Password.

Questo è progettato così di proposito ed è un punto di forza del modello REST API. Gli stessi controlli proteggono il tuo sito sia che qualcuno usi un'app per telefono, un client desktop o scriva uno script personalizzato.

Checklist riepilogativa

1. Leggi il codice di stato HTTP e il codice di errore dalla risposta effettiva. Confronta con la tabella diagnostica all'inizio.
2. Controlla il ruolo utente di WordPress. Deve includere upload_files (Autore o superiore tra quelli predefiniti).
3. Se il ruolo è corretto, disattiva i plugin di sicurezza uno alla volta e riprova i caricamenti.
4. Se nessun plugin è la causa, controlla il log eventi del tuo WAF; aggiungi un'eccezione di regola mirata per /wp-json/wp/v2/media solo per la regola specifica che è scattata.
5. Conferma che l'Application Password sia ancora elencata nel profilo dell'utente e che il tuo sito sia su HTTPS; rigenerala se necessario.
6. Verifica end-to-end con curl prima di tornare all'app client.

Seguire questo ordine risolve la maggior parte delle segnalazioni di "nessun permesso di caricamento" che vediamo dagli utenti di SnapPress. Il messaggio di errore sta facendo il suo lavoro; ha solo bisogno del giusto contesto per agire.

Domande frequenti

Perché WordPress restituisce 'Non hai i permessi per caricare' alla mia app per iPhone?

L'endpoint REST API /wp-json/wp/v2/media richiede che l'utente WordPress disponga della capability upload_files. I ruoli Sottoscrittore e Collaboratore non la possiedono. Se la tua app per iPhone si autentica come un utente con uno di questi ruoli, ogni tentativo di caricamento restituisce HTTP 403 con rest_cannot_create come codice di errore. Promuovere l'utente ad Autore (o a qualsiasi ruolo che includa upload_files) risolve il problema.

Sono l'amministratore del sito e continuo a ricevere 'nessun permesso di caricamento'. Cosa sta succedendo?

Quando il ruolo utente è corretto, la causa successiva più probabile è un plugin di sicurezza o una regola WAF che blocca la REST API. Wordfence, iThemes Security, Solid Security e i plugin "Disable REST API" hanno tutti impostazioni che possono respingere il traffico REST non originato dal browser. Le regole WAF di Cloudflare che mirano a /wp-json/ hanno lo stesso effetto. Usa il log degli eventi del tuo firewall per individuare la regola specifica che blocca, poi esonera solo quella regola per /wp-json/wp/v2/media.

L'Application Password di WordPress concede lo stesso ruolo dell'utente a cui appartiene?

Sì. Le Application Password vengono emesse per utente, e qualsiasi richiesta autenticata con esse viene eseguita come quell'utente con le sue esatte capability. Se l'utente sottostante è un Sottoscrittore, l'Application Password non può caricare, anche se è stata generata con successo. Le Application Password non hanno una scadenza integrata; rimangono valide finché non vengono revocate manualmente.

Come confermo la capability upload_files da un terminale?

Esegui curl con -u username:application-password e POST verso /wp-json/wp/v2/media con una piccola immagine di test. HTTP 201 con un corpo JSON contenente il nuovo media ID significa che i caricamenti funzionano. HTTP 403 con codice rest_cannot_create significa che il ruolo non ha upload_files. HTTP 401 con rest_invalid_authentication significa che l'Application Password è errata o revocata. HTTP 403 con un corpo di risposta non WordPress (pagina di errore HTML, challenge di Cloudflare) significa che un filtro a monte sta bloccando la richiesta prima che WordPress la veda.

Dovrei semplicemente promuovere l'utente ad Amministratore?

Solo come ultima risorsa, e solo per i siti che controlli completamente. Il principio del minimo privilegio dice che dovresti dare all'utente il ruolo più piccolo che concede upload_files, ovvero Autore. Riserva l'Amministratore agli account che hanno realmente bisogno di gestire impostazioni, plugin o altri utenti. Un ruolo personalizzato dedicato con solo upload_files più le capability di pubblicazione è ancora più sicuro per i siti condivisi.