Errore 401 Unauthorized: cosa significa e come risolverlo

L’errore 401 Unauthorized compare quando provi ad accedere a una risorsa protetta senza un’autenticazione valida. Nonostante il nome, il problema non è un’autorizzazione negata in senso stretto: il server ti sta dicendo che non sa chi sei, o che le credenziali che hai fornito non vanno bene. Fornendo quelle giuste, la porta si apre.

In questa guida vediamo da dove nasce il 401, come distinguerlo dal 403, quali sono le cause più frequenti e come risolverlo da visitatore, da gestore del sito e da sviluppatore che lavora con le API.

Cosa significa errore 401

Il codice 401 fa parte degli errori 4xx, quelli legati alla richiesta. Quando lo restituisce, il server include un’intestazione chiamata WWW-Authenticate che indica quale tipo di autenticazione è richiesta. Una risposta tipica ha questo aspetto:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Area riservata"

Nel caso più comune, l’autenticazione HTTP di base, il browser legge questa intestazione e mostra una finestra che chiede nome utente e password prima ancora di caricare la pagina. Il testo indicato in realm è il nome dell’area protetta, che a volte compare nella finestra stessa. Nelle API, invece, l’intestazione indica di solito uno schema come Bearer, che richiede un token di accesso.

Come si presenta

Il messaggio può comparire come 401 Unauthorized, Authorization Required, Accesso negato, HTTP Error 401 o, nelle risposte delle API, come un messaggio in formato JSON del tipo invalid_token o authentication required. Lo incontri tipicamente su aree riservate protette da password, pannelli di amministrazione, ambienti di staging, servizi di posta via web e interfacce di programmazione.

401 o 403: la differenza che conta

I due errori vengono spesso confusi, ma indicano situazioni diverse. Il 401 significa che manca un’autenticazione valida: il server ti dà la possibilità di identificarti. Il 403 significa che il server ti ha riconosciuto, o non ha bisogno di farlo, e rifiuta comunque l’accesso. Un esempio concreto: se apri un’area riservata senza aver fatto il login ricevi un 401; se fai il login con un utente che non ha i permessi per quella pagina ricevi un 403. Nel primo caso la soluzione è autenticarsi correttamente; nel secondo serve cambiare permessi o regole, come spiegato nella guida all’errore 403.

Le cause più comuni

Credenziali errate o scadute. Nome utente o password sbagliati, maiuscole e minuscole invertite, una password cambiata di recente ma ancora memorizzata nel browser nella versione vecchia. Anche un layout di tastiera diverso, per esempio inglese invece di italiano, può alterare i caratteri speciali della password senza che te ne accorga.

Area protetta con .htpasswd. Molti siti proteggono cartelle o ambienti di sviluppo con l’autenticazione HTTP del server, configurata tramite i file .htaccess e .htpasswd. Se il percorso del file delle password è sbagliato, se il file non è leggibile dal server o se l’utente non esiste più, anche chi conosce le credenziali riceve un 401.

Cache e cookie del browser. Il browser memorizza le credenziali di autenticazione e i cookie di sessione. Dati vecchi o corrotti possono continuare a inviare informazioni non valide, e con l’autenticazione di base il browser spesso non chiede di nuovo la password finché non lo chiudi.

Token o chiavi API non validi. Nelle applicazioni e nelle integrazioni, un 401 indica di solito una chiave API sbagliata, un token scaduto, un’intestazione di autorizzazione mancante o un orologio di sistema sfasato, che rende un token valido apparentemente scaduto.

Plugin di sicurezza o protezioni dell’hosting. Alcuni plugin aggiungono una password supplementare alla pagina di login, e alcuni hosting proteggono automaticamente le aree amministrative.

Come risolvere se sei un visitatore

Verifica che l’indirizzo sia corretto e di avere effettivamente diritto ad accedere. Reinserisci le credenziali con attenzione, controllando il tasto delle maiuscole e il layout della tastiera; se puoi, digita la password in un editor di testo per controllarla e poi copiala. Svuota cache e cookie del sito, oppure prova in una finestra in incognito, dove il browser non userà le credenziali memorizzate. Se hai dimenticato la password, usa la procedura di recupero del sito o chiedila a chi gestisce l’area riservata.

Come risolvere se il sito è tuo

1. Verifica le aree protette

Cerca nel file .htaccess della cartella interessata, e in quelle superiori, un blocco di direttive simile a questo:

AuthType Basic
AuthName "Area riservata"
AuthUserFile /home/utente/.htpasswd
Require valid-user

Controlla che il percorso indicato in AuthUserFile sia assoluto, cioè parta dalla radice del server, e che il file esista davvero in quella posizione. Un errore frequente dopo una migrazione è un percorso che conteneva il vecchio nome utente dell’hosting. Il file .htpasswd contiene una riga per utente, con il nome e la password cifrata separati da due punti: se l’utente che stai usando non c’è, va aggiunto. Per sicurezza, il file andrebbe conservato fuori dalla cartella pubblica del sito.

2. Controlla le protezioni del pannello

Molti pannelli di hosting offrono la funzione di protezione delle cartelle con password, che crea automaticamente i file necessari. Se l’hai attivata in passato su una cartella che ora deve essere pubblica, disattivala da lì invece di modificare i file a mano.

3. Verifica i plugin di sicurezza

Se il 401 compare sulla pagina di login di WordPress, disattiva temporaneamente il plugin di sicurezza rinominandone la cartella in wp-content/plugins via FTP e verifica se l’errore scompare. Se usi un plugin che aggiunge l’autenticazione HTTP alla bacheca, ricorda che quella password è diversa da quella del tuo utente WordPress.

4. Leggi i log

Il log del server mostra le richieste respinte con il codice 401 e, nell’error log, spesso il motivo, come un utente non trovato o una password non corrispondente. Trovi come fare nella guida ai log del server.

Esempio: proteggere uno staging con una password

Capire come si crea una protezione aiuta anche a correggerla quando non funziona. Supponiamo di voler proteggere la cartella di un ambiente di prova su un server Apache. Su un VPS, il primo passo è creare il file delle password con lo strumento htpasswd, conservandolo fuori dalla cartella pubblica:

htpasswd -c /home/utente/.htpasswd mario

Il comando chiede di digitare due volte la password e crea il file con l’utente mario. L’opzione -c crea un file nuovo e va usata solo la prima volta: ripeterla per aggiungere un secondo utente cancellerebbe il primo. Per gli utenti successivi si usa lo stesso comando senza -c.

Il secondo passo è aggiungere nel file .htaccess della cartella da proteggere il blocco di direttive visto prima, con il percorso esatto del file appena creato. Da quel momento ogni richiesta senza credenziali valide riceve un 401 e il browser mostra la finestra di accesso. Se invece del 401 ottieni un errore 500, quasi sempre il percorso del file è sbagliato o il server non permette queste direttive nel file .htaccess: il log degli errori lo indica chiaramente. Su un hosting condiviso, la funzione di protezione delle cartelle del pannello fa tutto questo con pochi clic.

Errore 401 nelle API e nelle integrazioni

Se il 401 arriva da un’integrazione, come un modulo collegato a un CRM, un’app mobile o un servizio che usa l’API REST di WordPress, la causa è quasi sempre nelle credenziali dell’integrazione. Controlla che la chiave o il token siano stati copiati per intero, senza spazi, e che non siano scaduti o revocati. Verifica che la richiesta includa davvero l’intestazione Authorization: alcuni server, configurati con PHP in modalità CGI o FastCGI, la eliminano prima che arrivi all’applicazione, e in quel caso serve una regola nel file .htaccess per inoltrarla.

Per l’API REST di WordPress, il metodo più semplice e sicuro per le integrazioni è usare le password per le applicazioni, che si generano dal profilo utente e si possono revocare singolarmente senza cambiare la password principale. Se ricevi un 401 con un token che fino a ieri funzionava, controlla anche data e ora del server: un orologio sfasato fa sembrare scaduti token perfettamente validi.

Errore 401 e SEO

Le pagine che restituiscono 401 non possono essere scansionate né indicizzate da Google, ed è esattamente ciò che vuoi per aree riservate e ambienti di staging. Proteggere uno staging con l’autenticazione del server è anzi il modo più sicuro per evitare che finisca nei risultati di ricerca, molto più affidabile di un semplice blocco nel file robots.txt. Il problema sorge solo se il 401 colpisce per errore pagine pubbliche: in quel caso Search Console lo segnala nel rapporto di indicizzazione e la pagina scompare dai risultati finché il blocco non viene rimosso.

Domande frequenti

Perché il browser continua a chiedermi la password anche se è giusta?

Probabilmente il server non trova il file delle password o l’utente al suo interno, oppure il browser sta inviando credenziali memorizzate in precedenza. Prova in una finestra in incognito; se il problema persiste, la configurazione lato server va corretta.

Come proteggo una cartella del sito con un errore 401?

Il modo più semplice è usare la funzione di protezione delle cartelle del pannello dell’hosting, che crea automaticamente i file necessari. In alternativa puoi configurare manualmente .htaccess e .htpasswd, conservando quest’ultimo fuori dalla cartella pubblica.

L’errore 401 può dipendere da un’estensione del browser?

Sì, anche se raramente. Gestori di password che compilano automaticamente credenziali sbagliate o estensioni che modificano le intestazioni delle richieste possono causarlo. Una finestra in incognito, dove le estensioni sono di solito disattivate, permette di escluderlo subito.