Come funziona questo controllo
Scanaris richiede la tua pagina in http://, senza la s, senza seguire i reindirizzamenti, e guarda cosa risponde il server. Se restituisce un codice di reindirizzamento (301, 302, 307 o 308) verso un URL https://, tutto bene. Se risponde 200 e serve la pagina in chiaro, apre un rilievo di gravità media: la versione non cifrata del tuo sito esiste e funziona. Se reindirizza ma la destinazione è ancora http:// (per esempio dalla radice a http://www), apre un rilievo di gravità bassa: la catena di reindirizzamenti ha un anello non cifrato. Viene testato solo l'URL scansionato; il comportamento dovrebbe essere lo stesso su tutte le rotte, non solo sulla home.
Perché è importante
Finché una versione HTTP risponde, qualsiasi vecchio link, qualsiasi indirizzo digitato a mano e qualsiasi rete pubblica possono portare l'utente sul tuo sito senza cifratura. In quello stato, chi controlla la rete (il wifi dell'aeroporto, un provider malevolo) legge ciò che viene inviato e può modificare la pagina prima che arrivi. È la base degli attacchi man-in-the-middle. Un 301 verso HTTPS chiude quella porta alla prima richiesta, e HSTS la chiude per tutte le successive.
Come risolvere a seconda del tuo hosting
- Vercel, Netlify, Cloudflare Pages, Railway, Render: il reindirizzamento è attivo di serie. Se vedi il rilievo, di solito il dominio punta a un altro server o un proxy davanti risponde in HTTP.
- Cloudflare come proxy: attiva «Always Use HTTPS» e imposta la modalità SSL su «Full (strict)». Con «Flexible», il tratto tra Cloudflare e il tuo server viaggia in chiaro.
- nginx:
server {
listen 80;
server_name tuodominio.it www.tuodominio.it;
return 301 https://$host$request_uri;
}
- Apache: nel VirtualHost della porta 80,
Redirect permanent / https://tuodominio.it/. - Express dietro un proxy: un middleware che controlla
req.headers['x-forwarded-proto'] !== 'https'e risponde conres.redirect(301, 'https://' + req.headers.host + req.url), conapp.set('trust proxy', 1).
Usa un 301 o un 308 (permanenti) e non un 302: i motori di ricerca consolidano l'autorità sulla versione HTTPS e i browser mettono in cache il salto. Aggiungi poi l'header HSTS, misurato dal controllo HSTS debole, così il browser non prova nemmeno più HTTP la volta successiva.
Verifica che sia risolto
curl -sI http://tuodominio.it | grep -iE "^HTTP|^location"
curl -sI http://tuodominio.it/una-pagina-qualsiasi | grep -iE "^HTTP|^location"
curl -sI http://www.tuodominio.it | grep -iE "^HTTP|^location"
Tutti e tre devono rispondere 301 o 308 con un Location che inizia con https://. Se il secondo non reindirizza, la tua regola copre solo la home.
Domande frequenti
Non basta avere HTTPS attivo?
No. Avere un certificato significa che la versione sicura esiste; il reindirizzamento significa che quella non sicura non viene usata. Senza di esso, coesistono entrambe.
Perché 301 e non 302?
Il 302 è temporaneo: i browser richiedono la versione HTTP ogni volta e i motori non trasferiscono l'autorità. Il 301 (o il 308, che conserva anche il metodo) è il segnale che il cambio è definitivo.
La mia API non ha bisogno di HTTPS, la usa solo la mia app.
Sì invece: per quell'API passano token e dati dei tuoi utenti. E se l'app la chiama in HTTP da una pagina HTTPS, il browser la blocca come contenuto misto.