L’errore HTTP 401 segnala un’autenticazione del sito web non riuscita
Un errore HTTP 401 è una risposta Hypertext Transfer Protocol che indica che un sito web ha ricevuto e compreso una richiesta, ma non ha accettato le credenziali che la accompagnavano. L’autenticazione, il processo utilizzato per confermare l’identità, può non riuscire perché una password, una application key o una credenziale di accesso è mancante, non valida nel formato, scaduta, revocata o semplicemente errata. I visitatori possono vedere una pagina vuota, un messaggio di accesso negato o una finestra del browser che richiede nome utente e password. Gli amministratori possono incontrare lo stesso ostacolo nelle proprie pagine di accesso.
Il codice appartiene alla famiglia di risposte 4xx, che comprende i problemi associati a una richiesta, anziché all’incapacità del server di elaborarla. Ciò non significa necessariamente che il problema sia stato causato dal visitatore. Una regola errata sul server può restituire errori HTTP 401 a tutti gli utenti legittimi. Anche la formulazione può generare confusione: 401 Unauthorized di solito significa non autenticato, perché il server non ha stabilito l’identità di chi ha effettuato la richiesta. Una risposta 403 è diversa. Significa che l’accesso viene rifiutato anche se l’identità è nota o se le credenziali non cambierebbero la decisione.
Una risposta 401 correttamente formata dovrebbe contenere un WWW-Authenticate header. Un header è un’informazione inviata insieme a una richiesta o risposta web e, in questo caso, identifica il tipo di autenticazione previsto, per esempio Basic o Bearer. L’autenticazione Basic invia un nome utente e una password codificati, mentre l’autenticazione Bearer utilizza un token emesso per un utente o un’applicazione approvati. I browser usano questo header per decidere se aprire una richiesta di credenziali. Gli sviluppatori possono esaminarlo nella sezione Network degli strumenti per sviluppatori del browser per individuare quale sistema richiede le credenziali.
Gli effetti immediati vanno oltre il semplice disagio di non riuscire ad accedere. I visitatori non possono raggiungere la pagina richiesta, mentre i crawler dei motori di ricerca considerano inaccessibili gli URL pubblici che restituiscono 401. Se la condizione persiste, le pagine pubbliche possono perdere visibilità nei risultati di ricerca. Un errore HTTP 401 in un percorso di amministrazione può inoltre impedire al proprietario di effettuare altre riparazioni. Per un’API, un’interfaccia di programmazione delle applicazioni tramite la quale i software scambiano richieste e dati, il problema può invece presentarsi come un corpo di errore JSON o XML, una voce nel log del client HTTP e un’attività non riuscita in un’altra parte dell’applicazione.
Le cause comuni iniziano da password modificate, account di servizio disabilitati, token scaduti e application key sottoposte a rotazione. Anche le sessioni di accesso possono diventare obsolete quando i cookie di autenticazione non corrispondono più al server. 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 chiavi di sessione da parte di un plugin WordPress. WordPress e altri sistemi di gestione dei contenuti, software utilizzati per creare e amministrare siti web, possono inoltre presentare conflitti tra componenti di sicurezza, iscrizione, caching e single sign-on. Tali conflitti possono interessare soltanto specifici ruoli utente o route.
La protezione tramite password a livello di server è un’altra causa frequente. Apache la applica comunemente tramite .htaccess, un file che contiene regole del server a livello di directory, insieme a un file di password .htpasswd. Nginx può applicare regole auth_basic equivalenti. Un file di password spostato, un formato di password illeggibile, permessi dei file errati o una protezione dell’ambiente di staging lasciata attiva dopo il lancio possono tutti provocare un errore 401. Un reverse proxy, che riceve il traffico prima di inoltrarlo al sito web, può rimuovere l’Authorization header. Analogamente, una content delivery network, un firewall o un load balancer possono applicare una regola di accesso trascurata oppure memorizzare nella cache una risposta protetta, causando errori intermittenti.
La risoluzione dei problemi dovrebbe iniziare dai controlli meno invasivi. Conferma il codice di stato esatto nel pannello Network del browser ed esamina gli header della risposta, in particolare WWW-Authenticate. Apri lo stesso indirizzo in una finestra privata e in un altro browser. Se lì funziona, elimina i cookie e i dati del sito memorizzati per il dominio, includendo, ove pertinente, sia la versione senza www sia quella con www, quindi accedi nuovamente. Determina se il problema interessa l’intero sito, soltanto /wp-admin/ oppure una singola route API. Reimposta la password, il token, l’API key o la application password pertinente prima di apportare modifiche al server.
Successivamente, crea un backup ed esamina .htaccess o la configurazione equivalente del server per individuare regole AuthType, AuthUserFile, Require o auth_basic. Verifica che il file di password esista e sia leggibile. La disattivazione temporanea del blocco pertinente può confermare se il problema è stato causato dall’autenticazione del server. Svuota le cache di plugin, server, oggetti, browser e content delivery network. Se la configurazione dell’hosting lo consente, prova il sito web di origine senza il proxy o il firewall. Se l’errore si verifica soltanto attraverso tale intermediario, occorre controllarne le regole o la gestione degli header.
Su WordPress, i plugin possono essere disattivati tutti insieme e poi riattivati uno alla volta finché il problema non si ripresenta. Se la dashboard non è accessibile, rinominare la directory dei plugin tramite Secure File Transfer Protocol (SFTP), un metodo crittografato per gestire i file del sito web, oppure tramite il file manager dell’hosting forza una disattivazione collettiva. La selezione temporanea di un tema predefinito può rivelare interferenze a livello di tema. I log di accesso, degli errori e del firewall del server possono mostrare quale componente ha restituito il codice 401 e quale percorso lo ha attivato. Anche il supporto dell’hosting può controllare la protezione dello staging, le regole edge e le restrizioni non visibili all’interno di WordPress.
Per le chiamate REST API, ovvero richieste effettuate tramite un’interfaccia web conforme alle convenzioni REST, registra la richiesta in uscita senza esporne i dati segreti. Conferma che l’Authorization header raggiunga la destinazione, in particolare attraverso configurazioni Apache CGI o FastCGI e proxy. Confronta la richiesta usando curl, uno strumento da riga di comando per effettuare richieste web, dalla stessa rete. Controlla che Bearer e Basic non siano stati confusi e che il token sia ancora valido. Un errore che si ripete regolarmente dopo un periodo di funzionamento corretto indica innanzitutto la possibile scadenza del token.
La REST API di WordPress prevede requisiti specifici. L’autenticazione basata sui cookie richiede un nonce valido, un valore di breve durata utilizzato per confermare che una richiesta provenga da una sessione autorizzata, per le operazioni di scrittura provenienti da contesti esterni. Le application password utilizzate per le richieste da server a server devono appartenere a un utente il cui ruolo disponga dell’autorizzazione per l’endpoint. Anche il percorso di base deve essere corretto, perché le regole di riscrittura o i plugin possono spostare le route REST. Se un firewall sottopone il traffico automatizzato a una verifica, limita qualsiasi allowlisting all’indirizzo dell’integrazione o alla route specifica, anziché ridurre la protezione a livello globale. Le richieste eccessive possono essere soggette a rate limiting, anche se normalmente ciò produce HTTP 429 anziché 401.
La maggior parte delle risposte 401 deriva dalla configurazione, ma uno schema inspiegabile può giustificare un’indagine di sicurezza. Tra i segnali di allarme figurano amministratori che improvvisamente non riescono più ad accedere mentre il sito pubblico continua a funzionare, una richiesta inattesa di password da parte del browser, errori simultanei su numerosi indirizzi oppure una reimpostazione della password che non ripristina l’accesso.