HTTP 401 error indica che l'autenticazione del sito web non è riuscita
Un HTTP 401 error è un codice di stato dell'Hypertext Transfer Protocol che indica che un server ha ricevuto e compreso una richiesta, ma non ha ricevuto credenziali accettabili. La password, l'application password, l'API key o l'access token possono essere assenti, non validi, scaduti, revocati o errati. Sebbene la denominazione ufficiale sia “Unauthorized”, il significato pratico è solitamente “non autenticato”: il server non riesce a stabilire chi stia effettuando la richiesta. Per confronto, una risposta 403 indica che il server rifiuta l'accesso anche se l'identità è nota o irrilevante.
Una risposta 401 corretta dovrebbe includere un WWW-Authenticate header, una parte delle informazioni di risposta che identifica il metodo di autenticazione previsto, come Basic o Bearer. Basic authentication invia credenziali codificate insieme alla richiesta, mentre Bearer authentication utilizza un access token. I browser possono reagire aprendo una finestra di dialogo per le credenziali. I siti web possono invece mostrare una pagina vuota o messaggi come “Authorization Required” o “Access denied due to invalid credentials.” Le applicazioni solitamente registrano l'errore nei propri log e ricevono un error body JSON o XML anziché una pagina visibile.
Le conseguenze dipendono dall'indirizzo interessato. I visitatori non possono proseguire, le pagine pubbliche possono diventare inaccessibili ai crawler dei motori di ricerca e perdere visibilità nei risultati finché l'errore persiste, mentre il blocco di un percorso di login o di amministrazione può impedire al proprietario del sito di effettuare le riparazioni. La protezione intenzionale dei percorsi di staging, amministrazione e API è normale. Il problema è la protezione accidentale di contenuti pubblici o un errore imprevisto che colpisce utenti legittimi.
Le cause comuni iniziano da credenziali modificate, disabilitate, sottoposte a rotazione o lasciate scadere. Anche una sessione di login obsoleta può far apparire anonimo un utente autenticato. Ciò può verificarsi dopo una modifica del dominio, un passaggio tra indirizzi www e non-www, una migrazione da HTTP a HTTPS o la rigenerazione delle session key da parte di un plugin. I plugin di sicurezza, membership, caching e single sign-on possono entrare in conflitto quando più di un componente controlla il login o la REST authorization, talvolta interessando solo determinati ruoli utente o endpoint.
L'autenticazione può essere imposta anche dal web server. Apache utilizza comunemente un file di configurazione .htaccess e un file di password .htpasswd, mentre Nginx può utilizzare un blocco auth_basic. Un file di password spostato, un formato delle password memorizzate illeggibile, permessi dei file restrittivi o una protezione di staging trasferita accidentalmente in production possono tutti restituire intenzionalmente una risposta 401. Un reverse proxy, che inoltra le richieste al sito web, o una content delivery network (CDN), che distribuisce i contenuti tramite sistemi distribuiti, può rimuovere l'Authorization header, memorizzare nella cache una risposta protetta o applicare una regola di accesso trascurata. Le pagine protette combinate con un caching aggressivo possono creare errori intermittenti difficili da riprodurre.
Il troubleshooting dovrebbe iniziare dai controlli meno invasivi. Apri gli strumenti per sviluppatori del browser, esamina la richiesta non riuscita nella scheda Network e verifica che la risposta sia realmente 401 anziché 403, 419 o un altro codice. Registra i response header, in particolare WWW-Authenticate. Prova lo stesso indirizzo in una finestra privata e con un altro browser. Se lì funziona, cancella i cookie e i dati del sito relativi al dominio, incluse le versioni www e non-www dove applicabile, quindi effettua nuovamente il login. Controlla se l'errore interessa l'intero sito, solo /wp-admin/ oppure una singola API route.
Successivamente, reimposta la specifica credenziale modificando la password, rigenerando l'API key o l'application password oppure emettendo un nuovo token. Esamina le direttive Apache come AuthType, AuthUserFile e Require, oppure il blocco auth_basic equivalente di Nginx. Verifica che il file di password esista e sia leggibile. Dopo aver creato un backup, la disabilitazione temporanea di quel blocco può stabilire se la causa sia l'autenticazione a livello di server.
Svuota tutte le cache pertinenti, incluse quella del browser, quella del plugin di caching di WordPress, la cache del server, l'object cache, che memorizza i risultati del database riutilizzati di frequente, e la CDN. Se possibile, prova l'hosting origin senza il proxy, la CDN o il firewall. Un errore che compare solo passando attraverso l'intermediario indica le sue regole di accesso, le risposte memorizzate nella cache o la gestione degli header.
I plugin devono essere verificati in modo metodico. Disattivali tutti, controlla se l'accesso viene ripristinato e riattivali uno alla volta finché l'errore non ricompare. Se la dashboard di WordPress non è accessibile, la directory dei plugin può essere rinominata tramite SFTP, un metodo sicuro per trasferire i file del sito, oppure tramite il file manager dell'host, per forzare la disattivazione in blocco. Ripristina il nome della directory prima di provare ciascun plugin. L'uso temporaneo di un tema predefinito può rivelare interferenze a livello del tema. Gli access log del server, gli error log e i log del firewall possono quindi identificare quale componente abbia prodotto la risposta e quale percorso sia stato interessato. Anche il supporto dell'hosting potrebbe riuscire a individuare protezioni di staging, restrizioni edge o challenge non visibili all'interno di WordPress.
Per una REST API, un'interfaccia attraverso la quale le applicazioni si scambiano richieste e dati, esamina la richiesta effettivamente inviata, rimuovendo i dati segreti dai log. Verifica che l'Authorization header raggiunga il server, poiché i proxy e alcune configurazioni Apache CGI o FastCGI possono eliminarlo. Confronta la richiesta con curl dalla stessa rete. Gli schemi Basic e Bearer non sono intercambiabili e la risposta WWW-Authenticate identifica ciò che l'endpoint si aspetta. Anche i token possono scadere o essere revocati; se una connessione smette di funzionare a intervalli regolari, occorre verificare innanzitutto la scadenza.
La cookie-based REST authentication di WordPress richiede un nonce, un valore di breve durata utilizzato per verificare che una richiesta sia intenzionale, per le operazioni di scrittura provenienti da contesti esterni. Essere autenticati non è sufficiente. Le application password vengono normalmente utilizzate per le richieste server-to-server, ma devono appartenere a un utente il cui ruolo disponga della capability richiesta dall'endpoint. Controlla anche il base REST path, perché le rewrite o i plugin possono spostare le route. Le regole del firewall possono sottoporre a challenge le chiamate automatizzate verso i percorsi di amministrazione o API. Inserire in allowlist solo l'indirizzo o la route dell'integrazione è più sicuro che indebolire globalmente una regola. Una frequenza eccessiva delle richieste produce normalmente una risposta 429 anziché 401.
La maggior parte degli errori 401 è dovuta a problemi di configurazione, ma uno schema inspiegabile può giustificare un'indagine di sicurezza. Tra i segnali di allarme rientrano amministratori che perdono improvvisamente l'accesso mentre il sito pubblico continua a funzionare, una finestra di dialogo per le credenziali che appare in un percorso mai protetto, errori che si estendono a molti indirizzi o una reimpostazione della password che non ripristina l'accesso. Codice iniettato in un tema, in un plugin o in un must-use plugin, che WordPress carica automaticamente, può alterare l'autenticazione, sostituire il login handler o imporre un ulteriore controllo degli accessi. Anche una rimozione incompleta del malware può lasciare authentication hook, mentre una protezione non autorizzata delle directory può essere finalizzata a escludere gli amministratori legittimi dall'accesso ottenuto da un aggressore.
Non considerare un errore 401, da solo, una prova di compromissione.