Ogni volta che navighi su un sito, invii un modulo o interagisci con un'API, dietro le quinte avviene uno scambio silenzioso ma fondamentale: il passaggio degli header HTTP. Questi metadati definiscono come il browser e il server devono interpretare i dati scambiati, gestendo aspetti cruciali come la sicurezza, la cache, l'autenticazione e il tipo di contenuto. Padroneggiare gli header HTTP è indispensabile per il debugging, l'ottimizzazione delle performance e la protezione delle applicazioni moderne.

Cosa sono esattamente gli Header HTTP?

Gli header HTTP sono coppie chiave-valore inviate all'inizio di ogni richiesta e risposta. Sebbene siano invisibili all'utente finale, sono il "linguaggio di coordinamento" tra client (browser), server, CDN e proxy. Questi parametri determinano se una risorsa può essere salvata in cache, quali formati di dati sono accettati e quali permessi di sicurezza sono attivi.

Esempio di Richiesta HTTP con Header
GET /api/v1/profile HTTP/1.1
Host: api.pantool.io
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json
Content-Type: application/json
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)

Content-Type: Definire l'Identità dei Dati

L'header Content-Type è probabilmente il più comune. Indica al destinatario qual è il tipo di media (MIME type) del corpo del messaggio. Senza questo header, il server o il browser non saprebbero se interpretare i dati come testo semplice, un'immagine o del codice JSON.

Valori Content-Type più Utilizzati
Content-Type: application/json (Per API REST)
Content-Type: application/x-www-form-urlencoded (Moduli HTML standard)
Content-Type: multipart/form-data (Upload di file)
Content-Type: text/html; charset=UTF-8 (Pagine web)
Content-Type: image/webp (Immagini ottimizzate)

Un errore frequente è l'invio di dati JSON con un Content-Type: text/plain. In questo caso, molti backend rifiuteranno la richiesta restituendo un errore 415 (Unsupported Media Type) perché non riconoscono il formato del payload.

Cache-Control: Strategie di Performance

Gestire correttamente la cache è il segreto per siti web veloci. L'header Cache-Control istruisce browser e proxy su come e per quanto tempo memorizzare una risorsa locale:

  • no-cache — Richiede la ri-validazione con il server prima di usare la copia cache.
  • no-store — Impedisce categoricamente la memorizzazione (usato per dati sensibili).
  • max-age=604800 — Indica che la risorsa è valida per una settimana (espressa in secondi).
  • public — La risposta può essere salvata da qualsiasi cache (inclusi CDN).
  • private — Solo il browser dell'utente finale può memorizzare il dato.
  • immutable — Indica che la risorsa non cambierà mai durante il suo tempo di vita.

Authorization: Sicurezza e Accesso alle API

L'header Authorization trasporta le credenziali necessarie per accedere a risorse protette. Gli standard attuali prevedono principalmente due metodi:

  • Bearer Token — Lo standard per JWT e OAuth 2.0: Authorization: Bearer <token>
  • Basic Auth — Username e password codificati in Base64: Authorization: Basic <base64(user:pass)>

Ricorda: la Basic Auth usa la codifica Base64, che non è una forma di crittografia. È obbligatorio utilizzarla esclusivamente su connessioni HTTPS per evitare l'intercettazione delle credenziali in chiaro.

CORS: Gestire le Richieste Cross-Origin

Il Cross-Origin Resource Sharing (CORS) è un meccanismo di sicurezza che permette ai server di specificare quali domini esterni sono autorizzati ad accedere alle proprie risorse. Senza questi header, i browser moderni bloccano le chiamate API effettuate da un dominio diverso da quello del server:

Header di Risposta CORS comuni
Access-Control-Allow-Origin: https://mio-sito.it
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Un errore critico di sicurezza è l'uso di Access-Control-Allow-Origin: * in combinazione con Access-Control-Allow-Credentials: true. Questa configurazione è vietata dai browser e causa il fallimento della richiesta per motivi di privacy.

Header di Sicurezza: Proteggere gli Utenti

Esistono header progettati specificamente per mitigare attacchi comuni come XSS o clickjacking:

  • Content-Security-Policy (CSP) — Definisce quali sorgenti di script e stili sono fidate, prevenendo l'iniezione di codice malevolo.
  • X-Frame-Options: DENY — Impedisce che il tuo sito venga inserito in un <iframe> di siti terzi, bloccando attacchi di clickjacking.
  • Strict-Transport-Security (HSTS) — Obbliga il browser a comunicare con il server solo tramite protocollo criptato HTTPS.
  • X-Content-Type-Options: nosniff — Impedisce al browser di ignorare il Content-Type dichiarato (evita l'esecuzione di script camuffati da immagini).

ETag e Risparmio della Banda

Gli header ETag e Last-Modified permettono il caching condizionale. Il server assegna un identificativo univoco (hash) a una risorsa. Se la risorsa non è cambiata, il server risponde con un codice 304 Not Modified senza inviare nuovamente il corpo della pagina, riducendo drasticamente il consumo di banda e i tempi di caricamento.

Compressione con Accept-Encoding

L'header Accept-Encoding permette al client di dichiarare quali algoritmi di compressione supporta (come Gzip o Brotli). Il server risponde poi con Content-Encoding per confermare quale metodo ha usato:

Header per la Compressione Dati
# Il client accetta questi formati:
Accept-Encoding: gzip, deflate, br

# Il server risponde usando Brotli (più efficiente di Gzip):
Content-Encoding: br

L'uso di Brotli (br) può ridurre le dimensioni di file CSS e JS del 20% in più rispetto al classico GZIP, migliorando sensibilmente il punteggio nei Core Web Vitals.

Gestisci le tue API con facilità

Devi codificare o decodificare credenziali per i tuoi header di autorizzazione? Prova i nostri strumenti gratuiti per sviluppatori.