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. Aggiornato il 22 luglio 2026 con una quinta causa principale relativa alle patch di sicurezza urgenti e il 30 luglio 2026 con una sesta causa principale misurata su un sito reale: le Application Passwords disattivate su tutto il sito.

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
401	rest_not_logged_in	Application Passwords disattivate su tutto il sito	Controlla authentication in /wp-json/ (vedi Causa principale 6)

Quell'ultima riga è quella che quasi tutti si perdono. rest_not_logged_in non significa password sbagliata: significa che WordPress non ha visto alcuna credenziale, e rigenerare la password non cambierà il risultato. La Causa principale 6 se ne occupa.

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.

Causa principale 5: una patch di sicurezza urgente ha cambiato le regole dall'oggi al domani

Le quattro cause principali sopra presuppongono che sia cambiato qualcosa a cui tu (o chiunque abbia accesso al tuo sito) possa risalire. Ma osserviamo sempre più spesso un quinto schema nelle richieste di supporto di SnapPress: i caricamenti hanno funzionato in modo affidabile per settimane o mesi, poi hanno iniziato a fallire con rest_cannot_create da un giorno all'altro, senza alcuna modifica di configurazione deliberata da parte del proprietario del sito.

Il fattore scatenante in questi casi è di solito un aggiornamento urgente che il proprietario del sito non ha avviato direttamente. Quando il core di WordPress divulga una vulnerabilità critica, tendono ad accadere due cose nel giro di poche ore: WordPress stesso rilascia una security release, e i fornitori di plugin di sicurezza (Wordfence, iThemes/Solid Security e altri) distribuiscono regole firewall aggiornate a ogni installazione attiva, spesso tramite aggiornamenti automatici in background. Un esempio recente: il 17 luglio 2026 WordPress ha divulgato una vulnerabilità critica della REST API (soprannominata "wp2shell", CVE-2026-63030) e ha rilasciato WordPress 6.8.6 / 6.9.5 / 7.0.2 lo stesso giorno; i principali fornitori di WAF hanno pubblicato nuove regole firewall per la REST API entro poche ore dalla divulgazione.

Queste regole d'emergenza sono di solito limitate in modo ristretto (in quel caso, a un singolo endpoint di elaborazione batch), ma configurazioni firewall più ampie o più conservative possono incidentalmente intercettare anche altro traffico REST API, incluso /wp-json/wp/v2/media. Separatamente, alcuni plugin di sicurezza includono un interruttore letterale "disabilita le Application Password" (in Wordfence: Firewall -> All Firewall Options -> Brute Force Protection -> Disable WordPress application passwords) che può essere attivato come parte di un aggiornamento di hardening, producendo esattamente il sintomo rest_cannot_create descritto nella Causa principale 1, anche se il ruolo dell'utente non è mai cambiato.

Come verificare se è questo che ti è successo

1. Annota la data esatta in cui i caricamenti hanno iniziato a fallire.
2. Nell'admin di WordPress, vai su Bacheca -> Aggiornamenti e confronta la versione del core di WordPress e la cronologia degli aggiornamenti con quella data.
3. Controlla il changelog o il registro degli aggiornamenti del tuo plugin di sicurezza per una release intorno alla stessa data — la maggior parte dei plugin la mostra nella propria pagina delle impostazioni o in Plugin -> Plugin installati.
4. Se usi Wordfence, conferma che Disable WordPress application passwords (sotto Brute Force Protection, in Firewall Options) sia disattivato.
5. Se un aggiornamento di un plugin coincide con la data del guasto, esegui temporaneamente un rollback o disattivalo per confermare, poi riattivalo con la specifica restrizione della REST API disattivata invece di lasciarlo disattivato.

Questa causa principale non sostituisce le prime quattro — spiega perché un sito configurato correttamente ieri può fallire oggi. La correzione di fondo resta comunque una delle Cause principali da 1 a 4; questa sezione serve solo a indirizzarti più velocemente verso quella giusta quando non è stato cambiato nulla di proposito.

Causa principale 6: le Application Passwords sono disattivate su tutto il sito

Le cinque cause precedenti presuppongono tutte che l'autenticazione tramite Application Password funzioni. Esiste un sesto caso in cui non funziona, ed è il più disorientante da vivere, perché tutto quello che provi fallisce esattamente nello stesso modo. Digitare la password a mano fallisce. Incollarla fallisce. Scansionare un codice QR di abbinamento fallisce. Rigenerare la password e ricominciare da zero fallisce. Promuovere l'utente ad Amministratore fallisce.

È proprio questo schema l'indizio. Il sito non sta rifiutando le tue credenziali: si rifiuta di elaborarle.

La diagnosi con un solo comando

WordPress pubblica nella radice della REST API quali metodi di autenticazione il sito accetta. Apri https://il-tuo-sito.example/wp-json/ in un browser e cerca il campo authentication, oppure leggilo direttamente:

curl -s https://your-site.example/wp-json/ \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['authentication'])"

# attivo       -> {'application-passwords': {'endpoints': {'authorization': '...'}}}
# disattivato  -> []

Un sito WordPress integro elenca application-passwords insieme al suo endpoint di autorizzazione. Se il campo è vuoto, il sito sta dicendo a ogni client che non è disponibile alcun metodo di autenticazione. Nessuna app può collegarsi e reinserire le credenziali non cambierà nulla.

Una seconda richiesta lo conferma dall'altro lato. Invia credenziali deliberatamente non valide a una rotta che richiede autenticazione:

curl -s -u 'diagnostic:deliberately-invalid' \
  https://your-site.example/wp-json/wp/v2/users/me

# {"code":"rest_not_logged_in", ...}   le credenziali non hanno mai raggiunto WordPress
# {"code":"incorrect_password", ...}   le credenziali sono state elaborate (solo sbagliate)

La distinzione conta. incorrect_password significa che WordPress ha analizzato il tuo header Authorization e ne ha respinto il contenuto: un normale problema di credenziali. rest_not_logged_in significa che l'header non è stato elaborato affatto, quindi la richiesta è stata eseguita come visitatore anonimo. I visitatori anonimi non possono creare media, ed è per questo che il sintomo visibile è spesso il messaggio rest_cannot_create della Causa principale 1, anche se il ruolo dell'utente è perfettamente corretto.

Confermarlo nel pannello di amministrazione

Accedi a WordPress e apri Utenti -> Profilo, poi scorri fino in fondo. Se la funzione è disponibile, vedrai una sezione Password per applicazioni con un campo per il nome della nuova password. Se quella sezione manca del tutto, o mostra un avviso che dice che le password per applicazioni non sono disponibili, la funzione è stata spenta per l'intero sito.

Che cosa la spegne

• Un'impostazione di un plugin di sicurezza. Wordfence ha una casella esplicita chiamata Disable WordPress application passwords, ma non è affatto la sola: Solid Security, All In One WP Security, Sucuri e Shield Security includono interruttori di hardening equivalenti. Non smettere di cercare solo perché non usi Wordfence.
• Il tuo provider di hosting. Gli hosting gestiti a volte disattivano la funzione a livello di piattaforma tramite un must-use plugin in wp-content/mu-plugins/, che non compare mai nell'elenco normale dei plugin e non può essere disattivato dalla bacheca. È la variante più difficile da trovare e spiega come i caricamenti si rompano su un sito il cui proprietario non ha davvero cambiato nulla: la modifica è avvenuta un livello più sotto, spesso come parte di un giro di hardening successivo a una release di sicurezza di WordPress.
• Codice personalizzato. Qualsiasi tema o plugin può restituire false dal filtro wp_is_application_passwords_available. Cerca quel nome di filtro in tutto il codice.
• Siti senza HTTPS. WordPress offre le Application Passwords solo su HTTPS. Se il tuo sito è ancora servito in HTTP semplice, o termina il TLS in un modo che lascia is_ssl() a false, la funzione resta non disponibile.

In un caso che abbiamo diagnosticato a luglio 2026, lo store di un utente SnapPress caricava foto senza problemi da mesi e poi si è fermato. Wordfence non era installato. La REST API era perfettamente raggiungibile: /wp-json/ e /wp-json/wp/v2/types/post restituivano entrambi 200, quindi nulla veniva bloccato da un firewall. L'unica anomalia era un campo authentication vuoto su un sito ospitato su LiteSpeed, il che spiegava tutti i sintomi in un colpo solo, incluso il motivo per cui inserimento manuale e abbinamento QR fallivano esattamente nello stesso modo.

Come risolvere

1. Riattiva l'impostazione nel plugin di sicurezza che la controlla, genera una nuova Application Password e ricollega l'app.
2. Se nessuna impostazione di plugin lo spiega, chiedi direttamente al tuo host se le Application Passwords sono disattivate a livello di piattaforma, e ispeziona wp-content/mu-plugins/ se hai accesso ai file.
3. Se ti serve che funzioni subito e non riesci a individuare l'origine, forza la riattivazione da un must-use plugin o dal functions.php del tuo tema:

add_filter( 'wp_is_application_passwords_available', '__return_true', 999 );

L'argomento di priorità (999) è deliberato: fa girare il tuo filtro dopo ciò che ha disattivato la funzione. Trattalo come una forzatura puntuale e non come un sostituto della ricerca della causa: se un host ha spento la funzione di proposito, conviene sapere perché prima di scavalcarlo.

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.
7. Se non è stato cambiato nulla di proposito, confronta la data del guasto con i log di aggiornamento del core di WordPress e del plugin di sicurezza: una patch urgente è la spiegazione più probabile.
8. Se tutte le credenziali che provi falliscono nello stesso modo, leggi il campo authentication in /wp-json/. Un valore vuoto significa che le Application Passwords sono disattivate su tutto il sito e che nulla di ciò che fai nell'app potrà funzionare finché la situazione non viene ripristinata.

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.

I caricamenti hanno funzionato bene per mesi e improvvisamente hanno smesso. Non ho cambiato nulla dal mio lato. Cosa è successo?

Il motivo più comune per un errore di permesso improvviso e inspiegabile è un aggiornamento di sicurezza urgente distribuito senza il tuo coinvolgimento diretto: una security release del core di WordPress, oppure una regola firewall distribuita automaticamente dal tuo plugin di sicurezza. Queste patch a volte inaspriscono il comportamento della REST API o delle Application Password come effetto collaterale della chiusura di una vulnerabilità. Controlla la tua versione di WordPress e il changelog del tuo plugin di sicurezza per aggiornamenti intorno alla data in cui i caricamenti hanno smesso di funzionare; se uno è arrivato entro un giorno o due dal guasto, quello è il tuo principale sospettato.

Come capisco se le Application Passwords sono disattivate sul mio sito?

Apri https://il-tuo-sito.example/wp-json/ in un browser e guarda il campo authentication. Un sito integro annuncia application-passwords insieme al suo endpoint di autorizzazione. Se quel campo è vuoto, le Application Passwords sono disattivate su tutto il sito e nessuna app può autenticarsi, indipendentemente da quante volte rigeneri la password. Una seconda verifica lo conferma: invia una richiesta con credenziali deliberatamente non valide a /wp-json/wp/v2/users/me. Il codice rest_not_logged_in significa che le credenziali non vengono elaborate affatto, mentre incorrect_password significa che sono state elaborate e sono semplicemente sbagliate.