HSTS preload

Cosa verifica questo controllo

Cerca il tuo dominio nella HSTS preload list di Chromium — una lista statica di domini HTTPS-only compilata direttamente in Chrome, Firefox, Safari, Edge e Brave. Per i domini in lista, i browser rifiutano connessioni HTTP in chiaro dalla primissima richiesta, prima ancora che venga visto un header.

Il controllo restituisce uno tra: preloaded, pending submission, not preloaded, o removal in progress.

Perché è importante

HSTS chiude la finestra dell’attacco di downgrade — ma solo dopo che un browser ha visto l’header almeno una volta. La primissima visita di un utente al tuo dominio è ancora in chiaro. Su Wi-Fi ostile o con un router compromesso, un attaccante può intercettare quella prima richiesta, spogliare il redirect verso HTTPS e servire una versione malevola del tuo sito prima che HSTS entri in gioco.

Il preload elimina la finestra. Il browser sa che il tuo dominio è HTTPS-only prima che l’utente digiti l’URL. Anche su un’installazione vergine senza cronologia, la prima richiesta è cifrata.

Conta soprattutto per: banking, sanità, account con credenziali di valore, flussi di pagamento e qualunque sito dove la prima visita potrebbe compromettere l’utente. Per un sito di marketing senza autenticazione, il preload è un buon segnale di maturità operativa ma non load-bearing.

Il compromesso: il preload è difficile da annullare. La rimozione richiede tipicamente 6–12 settimane via canale stable di Chrome, e gli utenti su browser più vecchi restano bloccati anche più a lungo. Invia solo quando sei certo che il tuo dominio parlerà HTTPS per sempre.

Come sistemarlo

1. Verifica i prerequisiti prima della submission.

Per la policy di hstspreload.org, il tuo sito deve:

• Servire un certificato HTTPS valido sul dominio apex e su www.
• Fare redirect HTTP → HTTPS sullo stesso host (vedi redirect HTTP a HTTPS).
• Inviare un header HSTS su ogni risposta HTTPS con:
  • max-age ≥ 31536000 (un anno)
  • includeSubDomains
  • preload
• Servire anche tutti i sottodomini in HTTPS — includeSubDomains lo intende letteralmente.

L’header pronto per la produzione:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Due anni è il valore convenzionale una volta che sei sicuro.

2. Configura l’header.

nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Cloudflare: SSL/TLS → Edge Certificates → HSTS → imposta max-age a 12+ mesi, abilita Include subdomains, abilita Preload, abilita No-Sniff Header.

3. Verifica prima di inviare.

curl -sI https://tuodominio.com | grep -i strict-transport-security
curl -sI https://www.tuodominio.com | grep -i strict-transport-security
curl -sI https://qualsiasisottodominio.tuodominio.com | grep -i strict-transport-security

Tutti e tre devono restituire l’header con tutte e tre le direttive. Se a un sottodominio manca l’header o serve non-HTTPS, la submission verrà rifiutata.

4. Invia su hstspreload.org.

Inserisci il dominio su hstspreload.org, accetta gli avvisi, clicca Submit. Il form esegue la stessa verifica del controllo manuale sopra. I domini approvati atterrano nella release Chrome successiva (6–12 settimane fino a stable). Firefox, Safari ed Edge prendono dalla lista Chromium con la propria cadenza.

5. Pianifica il peggio prima di inviare.

Passa in rassegna queste modalità di fallimento e conferma che ognuna è accettabile:

• Certificato che scade senza presidio. Gli utenti prendono un hard error senza fallback HTTP. Automatizza il rinnovo (Let’s Encrypt + timer certbot o il managed cert del tuo cloud provider).
• Sottodominio che ha bisogno di HTTP (dispositivo legacy, IoT, tool interno). Non funzionerà. Sei vincolato a HTTPS ovunque per l’eTLD+1.
• Acquisizione / dominio venduto. Il nuovo proprietario eredita la voce preload finché la rimozione non si completa. Chi compra dovrebbe controllare la preload list prima dell’acquisto.
• Dominio interno inviato per sbaglio. La rimozione richiede mesi. Invia solo domini pubblici di produzione.

6. Rimozione, se mai ti servisse.

Invia una richiesta di rimozione su hstspreload.org. Il dominio viene tolto al prossimo aggiornamento Chromium (~6 settimane). Installazioni browser più vecchie restano bloccate per quanto dice il loro max-age, e utenti che non aggiornano Chrome possono restare bloccati per un anno o più. Abbassa max-age a un valore piccolo (es. 300) con largo anticipo per limitare il lock-in residuo.

Domande frequenti

Mi serve il preload se ho già HSTS?

Per la maggior parte dei siti di marketing, no. L’HSTS semplice protegge tutti dopo la prima visita, e basta quando non c’è auth o pagamento. Il preload conta quando (a) gestisci credenziali, denaro o PHI, (b) puoi garantire HTTPS per sempre e (c) hai già HSTS in produzione da almeno qualche mese senza problemi.

Quanto ci vuole davvero per apparire in Chrome?

Dalla submission alla prima release Chrome stable: tipicamente 6–12 settimane. Il form dirà “pending” fino alla prossima compilazione della lista, poi “pending preload” mentre passa per i canali di release di Chrome (canary → dev → beta → stable). Firefox, Safari ed Edge prendono dalla lista Chromium con i loro cicli — calcola 3–6 mesi per copertura ampia.

Posso fare il preload di un solo sottodominio, come app.example.com?

Sì, ma solo se l’eTLD+1 padre non è già preloadato. Invia direttamente app.example.com. Gli stessi prerequisiti si applicano (header HSTS con direttiva preload, HTTPS ovunque su quel hostname). È l’approccio giusto quando controlli un sottodominio ma non puoi impegnare l’intera organizzazione a HTTPS-per-sempre.