Sì, dovresti.
Nel tuo scenario, l'utente digita il nome del tuo dominio nella barra degli indirizzi del browser. Nessun protocollo, nessun www.
, solo example.com
. La maggior parte dei browser risponderà provando prima a connettersi a http://example.com
. Ora un utente malintenzionato ha l'opportunità di interferire con questa richiesta e / o la risposta, impedendo che si verifichi un reindirizzamento o reindirizzando l'utente alla destinazione sbagliata o qualsiasi altro comportamento scorretto.
Semplicemente supporto HTTPS sul dominio di base non aiuta in questo, poiché il browser si connetterà comunque su HTTP prima e l'attaccante controlla cosa succede da quel momento in poi. (Sebbene abbia il vantaggio minore di fornire una migliore esperienza per quei rari utenti che digitano https://example.com
nei loro browser).
L'unico modo per evitare il problema è se, quando l'utente digita example.com
, il browser si connette immediatamente tramite HTTPS , senza attendere un reindirizzamento. Ciò può essere ottenuto (nella maggior parte dei browser) inserendo il tuo dominio nell ' elenco di precaricamento HSTS. I requisiti per l'aggiunta di un dominio all'elenco di precaricamento implicano che il dominio di base deve essere disponibile su HTTPS (puoi inviare solo il dominio di base per l'inclusione, ed è quello che verrà verificato per i primi due requisiti; inoltre, l'intestazione HSTS come specificato nel quarto requisito è valida solo su HTTPS).
Quindi, la risposta alla tua domanda è sì - dovresti proteggere il dominio di base - ma dovresti anche considerare di soddisfare l'altro requisiti e aggiungendo il dominio all'elenco di precaricamento.