400 Bad Request: cosa significa e come risolverlo

2026-09-16 Aggiornato: 2026-09-19

Un 400 Bad Request significa che il server non è riuscito a interpretare la richiesta affatto, prima ancora di arrivare a decidere se permetterla. Questo colloca il 400 un passo prima di errori come 401 o 403, che significano che il server ha capito la richiesta perfettamente e poi l'ha rifiutata per una questione di policy.

Cosa significa 400 Bad Request

RFC 9110 definisce il 400 come il modo in cui il server dice che la richiesta non è stata compresa a causa di una sintassi malformata. La parola chiave è sintassi: il server non sta valutando chi sei, cosa hai il permesso di fare, o se la risorsa esiste. Sta dicendo che la richiesta stessa, come byte sul filo, non viene interpretata come una richiesta HTTP valida. Può trattarsi della request line, degli header o del corpo, a seconda di dove il parser si arrende.

Come appare l'errore

I browser mostrano qualunque pagina di errore semplice il server rimandi indietro per un 400; non esiste una pagina dedicata a livello di browser come per un fallimento DNS o del certificato, dato che la connessione è riuscita e una risposta è arrivata davvero. Una variante comune recita esattamente "400 Bad Request - request header or cookie too large", che nomina la causa direttamente. Dalla riga di comando:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

I log del server sono la prova più utile qui, perché a differenza di un fallimento dell'handshake TLS, la richiesta ha davvero raggiunto il livello applicativo e viene registrata, spesso con l'header o la riga specifica che non è riuscita a essere interpretata.

Cosa causa un 400 Bad Request

Per un visitatore, nell'ordine in cui è più probabile incontrarli davvero:

Cookie sovradimensionati o corrotti. Anni di cookie accumulati per un dominio, oppure un cookie danneggiato da un'estensione o da un redirect malfunzionante, producono regolarmente esattamente il messaggio "400 Bad Request - request header or cookie too large" una volta che la dimensione totale degli header supera il limite del server.
Un URL digitato male o codificato male. Un carattere estraneo, uno spazio non codificato, o una sequenza di percent-encoding rotta nella barra degli indirizzi o in un link incollato può non riuscire a essere interpretata come sintassi valida.
Un'estensione del browser che modifica le richieste. Ad blocker, strumenti per la privacy e alcune estensioni VPN riscrivono header o la request line, e un bug in uno di questi può consegnare al server qualcosa di malformato.
Un redirect in cache che punta a un URL rotto. Il browser segue un redirect obsoleto verso un URL che è a sua volta non valido, e il 400 compare sulla destinazione, non sul link che hai effettivamente cliccato.
Un caricamento di file più grande di quanto il server permetta. Alcune configurazioni server rispondono a un upload sovradimensionato con 400 invece del più specifico 413 Payload Too Large.

Per chi gestisce il sito, all'incirca nell'ordine da controllare per primo:

Limiti di dimensione di header o cookie impostati troppo bassi rispetto a ciò che l'applicazione invia davvero, specialmente dopo aver aggiunto cookie di tracciamento, JWT negli header, o un meccanismo di sessione che cresce nel tempo.
Un header Host non valido o mancante, che un reverse proxy o un client mal configurato possono produrre, e che la maggior parte dei server richiede per instradare la richiesta affatto.
Un Content-Length che non corrisponde al corpo effettivamente inviato, che un client difettoso o un proxy bacato nel mezzo possono causare.
Regole del web application firewall o di ModSecurity che rifiutano una richiesta la cui sintassi sembra corretta a un umano ma corrisponde a un pattern difensivo che il WAF tratta come malformato.
Un'API che rifiuta deliberatamente JSON malformato con 400. Questo è comportamento corretto, non un bug: un corpo di richiesta che non riesce a essere interpretato come JSON valido, o a cui manca un campo obbligatorio che l'API convalida a livello di sintassi, dovrebbe restituire 400 per progettazione.

Come capire di chi è la colpa

Riproduci la stessa richiesta da un ambiente pulito: una finestra di navigazione privata senza estensioni e senza cookie accumulati, oppure una semplice chiamata curl allo stesso URL. Se la richiesta pulita ha successo, la causa era locale, il più delle volte cookie o un'estensione. Se fallisce in modo identico da un client pulito e da un posto completamente diverso, sono i limiti o le regole del server stesso a rifiutare una richiesta formata legittimamente, e il modo più veloce per confermarlo su larga scala è eseguire un controllo HTTP da più postazioni contemporaneamente e confrontare il codice di stato che ciascuna restituisce.

Come correggere un 400 Bad Request

Se sei un visitatore

Cancella prima i cookie per il sito, dato che cookie sovradimensionati o corrotti sono di gran lunga la causa più comune. La maggior parte dei browser ti permette di cancellare i cookie per un solo sito senza eliminare ogni altro login.
Riprova in una finestra privata o in incognito. Una finestra pulita non ha cookie accumulati e, a seconda del browser, disattiva la maggior parte delle estensioni per impostazione predefinita, il che isola entrambe le cause comuni in una volta sola.
Controlla l'URL per errori di battitura o caratteri estranei, specialmente dopo aver incollato un link da qualche posto che potrebbe aver aggiunto parametri di tracciamento o rotto la codifica.
Disattiva le estensioni una alla volta se l'errore persiste in una finestra normale ma non in navigazione privata, per trovare quale sta riscrivendo la richiesta.
Prova un dispositivo o una rete diversi per escludere un captive portal o un proxy locale che non ha nulla a che fare con il sito.

Se gestisci il sito

Alza i limiti di header e buffer se l'applicazione ne ha davvero bisogno di più grandi. Su nginx:
```
large_client_header_buffers 4 16k;
```
Su Apache:
```
LimitRequestFieldSize 16384
```
Su IIS, controlla sia maxRequestLength in web.config per il corpo della richiesta sia l'impostazione di registro MaxFieldLength di HTTP.sys per i singoli campi header.
Riduci ciò che stai effettivamente inviando in cookie e header invece di alzare solo il tetto massimo. Ripulire i cookie obsoleti, spostare i token grandi fuori dagli header, e impostare durate dei cookie più brevi previene che il problema si ripeta man mano che l'uso cresce.
Controlla la gestione dell'header Host al reverse proxy o al load balancer, e conferma che stia inoltrando un valore valido e atteso all'applicazione.
Leggi i log del WAF o di ModSecurity per la regola specifica che è scattata, se ce n'è uno davanti all'applicazione; un falso positivo lì richiede un'eccezione mirata, non un set di regole disattivato.
Conferma che un 400 dalla tua API sia intenzionale prima di "correggerlo". Un corpo JSON malformato o un campo che fallisce la convalida a livello di sintassi dovrebbe restituire 400; la correzione in quel caso sono messaggi di errore lato client più chiari, non cambiare il codice di stato.

400 contro codici simili

401 Unauthorized significa che la richiesta è stata capita bene, ma mancano credenziali valide o sono state rifiutate.
403 Forbidden significa che la richiesta è stata capita bene, ma il server rifiuta di autorizzarla indipendentemente dalle credenziali.
404 Not Found significa che la richiesta è stata capita bene e nessuna risorsa corrispondeva al percorso.
413 Payload Too Large è il codice specifico per un corpo che supera un limite di dimensione, anche se in pratica alcuni server rispondono 400 invece.
414 URI Too Long è il codice specifico per una request line che supera un limite di lunghezza.
422 Unprocessable Content significa che la sintassi è stata interpretata correttamente ma la semantica no, per esempio JSON valido con un valore che fallisce la convalida di business, una distinzione più fine di quella che la maggior parte delle API si preoccupa di fare rispetto al 400.

Come prevenire che un errore 400 mandi giù una pagina

Un 400 introdotto da un deploy che ha stretto i limiti degli header, o un aggiornamento di una regola WAF che inizia a corrispondere al traffico legittimo, non apparirà come un crash o un timeout, dato che il server risponde istantaneamente e correttamente secondo le proprie regole. Un controllo HTTP pianificato con un'asserzione sul codice di stato atteso lo cattura nel momento in cui inizia a succedere, invece di aspettare che si accumulino ticket di supporto. Combinato con il monitoraggio da più postazioni, ti dice anche se il 400 è universale o legato alla configurazione edge di una sola regione.

Errori correlati

La famiglia più ampia dei codici di errore client e server è trattata nella panoramica 4xx. Vedi anche 403 Forbidden per richieste che il server ha capito e rifiutato, 404 Not Found per richieste dirette a una risorsa che non esiste, e 429 Too Many Requests per richieste rifiutate a causa della frequenza piuttosto che della sintassi.

Domande frequenti

Perché cancellare i cookie corregge un errore 400?

Perché i cookie viaggiano come header di richiesta su ogni richiesta, e un server impone una dimensione massima totale degli header. Anni di cookie accumulati, o un solo cookie corrotto, possono spingere il totale oltre quel limite, e il server risponde 400 prima ancora di leggere qualsiasi altra cosa della richiesta.

Un errore 400 è uguale su ogni sito web che visito?

Il codice e la causa generale, una sintassi di richiesta malformata, sono gli stessi ovunque, ma il limite esatto che è stato superato e il testo esatto della pagina di errore sono impostati dalla configurazione del server di ciascun sito.

La mia API dovrebbe restituire 400 per input non valido?

Sì, quando l'input non riesce a essere interpretato o manca un campo che l'API controlla a livello di sintassi. Questo è il 400 che funziona come previsto, non un bug da correggere allentando la convalida.

Un WAF può causare un errore 400 su una richiesta che sembra completamente normale?

Sì. Una regola WAF può segnalare un pattern in un URL, un header o un corpo che è tecnicamente HTTP valido ma corrisponde a una firma difensiva, e alcune configurazioni WAF rispondono con un 400 generico invece di una pagina di blocco più specifica.

Qual è la differenza tra 400 e 413?

413 è il codice specifico per un corpo di richiesta che supera un limite di dimensione configurato. Molti server lo usano correttamente, ma alcuni rispondono 400 invece per la stessa condizione di corpo sovradimensionato, quindi non dare per scontato che il codice da solo ti dica la causa esatta senza controllare la documentazione o i log del server.