Cette page a été traduite par l'API Cloud Translation.

Quand utiliser HTTPS pour le développement local ?

L'utilisation de http://localhost pour le développement local est acceptable la plupart du temps, sauf dans certains cas particuliers. Cet article vous explique dans quels cas vous devez exécuter votre site de développement local avec HTTPS.

Maud Nalpas

Consultez également Utiliser le protocole HTTPS pour le développement local.

Dans cet article, les instructions concernant localhost sont également valables pour 127.0.0.1 et [::1], car elles décrivent toutes les deux l'adresse de l'ordinateur local, également appelée "adresse de bouclage". En outre, pour plus de simplicité, le numéro de port n'est pas spécifié. Lorsque vous voyez http://localhost, lisez-le comme http://localhost:{PORT} ou http://127.0.0.1:{PORT}.

Résumé

Lorsque vous développez en local, utilisez http://localhost par défaut. Les service workers, l'API Web Authentication, etc. fonctionneront. Toutefois, dans les cas suivants, vous aurez besoin du protocole HTTPS pour le développement local:

Configuration cohérente des cookies sécurisés dans les différents navigateurs
Déboguer les problèmes de contenu mixte
Utilisation de HTTP/2 et versions ultérieures
Utiliser des bibliothèques ou des API tierces nécessitant HTTPS
Utiliser un nom d'hôte personnalisé

Quand utiliser le protocole HTTPS pour le développement local ?

✨ Voilà tout ce que vous avez besoin de savoir. Si vous souhaitez en savoir plus, poursuivez votre lecture !

Pourquoi votre site de développement doit se comporter de façon sécurisée

Pour éviter tout problème inattendu, votre site de développement local doit se comporter le plus possible comme votre site Web de production. Ainsi, si votre site Web de production utilise HTTPS, vous souhaitez que votre site de développement local se comporte comme un site HTTPS.

Utiliser `http://localhost` par défaut

Les navigateurs traitent http://localhost d'une manière particulière: bien qu'il s'agisse d'un protocole HTTP, il se comporte principalement comme un site HTTPS.

Sur http://localhost, les service workers, les API Sensor, les API d'authentification, les paiements et d'autres fonctionnalités nécessitant certaines garanties de sécurité sont pris en charge et se comportent exactement comme sur un site HTTPS.

Quand utiliser le protocole HTTPS pour le développement local ?

Vous pouvez rencontrer des cas particuliers où http://localhost ne se comporte pas comme un site HTTPS ou vous pouvez simplement utiliser un nom de site personnalisé autre que http://localhost.

Vous devez utiliser HTTPS pour le développement local dans les cas suivants:

Vous devez définir un cookie localement de façon Secure ou SameSite:none, ou avec le préfixe __Host. Les cookies Secure sont définis uniquement sur HTTPS, mais pas sur http://localhost pour tous les navigateurs. Étant donné que SameSite:none et __Host nécessitent également que le cookie soit Secure, la définition de ces cookies sur votre site de développement local nécessite également le protocole HTTPS.

Lorsqu'il s'agit de définir des cookies Secure localement, tous les navigateurs ne se comportent pas de la même manière. Par exemple, Chrome et Safari ne définissent pas de cookies Secure sur localhost, contrairement à Firefox. Dans Chrome, cela est considéré comme un bug.
Vous devez déboguer en local un problème qui ne se produit que sur un site Web HTTPS, mais pas sur un site HTTP, pas même http://localhost, comme un problème de contenu mixte.
Vous devez tester ou reproduire localement un comportement spécifique au protocole HTTP/2 ou version ultérieure. (par exemple, si vous devez tester les performances de chargement sur HTTP/2 ou une version ultérieure). Les protocoles HTTP/2 ou version ultérieure ne sont pas compatibles, pas même sur localhost.
Vous devez tester localement les bibliothèques ou les API tierces qui nécessitent HTTPS (par exemple, OAuth).
Vous n'utilisez pas localhost, mais un nom d'hôte personnalisé pour le développement local, par exemple mysite.example. En général, cela signifie que vous avez remplacé votre fichier d'hôtes locaux:

Modifier un fichier d'hôtes pour ajouter un nom d'hôte personnalisé

Dans ce cas, Chrome, Edge, Safari et Firefox par défaut ne considèrent pas mysite.example comme sécurisé, même s'il s'agit d'un site local. Il ne se comportera donc pas comme un site HTTPS.
Autres cas ! Cette liste n'est pas exhaustive, mais si vous rencontrez un problème qui n'est pas répertorié ici, sachez que tout fonctionnera correctement sur http://localhost ou qu'il ne se comportera pas tout à fait comme votre site de production. 🙃

Dans tous ces cas, vous devez utiliser le protocole HTTPS pour le développement local.

Utiliser le protocole HTTPS pour le développement local

Si vous devez utiliser HTTPS pour le développement local, consultez Utiliser le protocole HTTPS pour le développement local.

Conseils si vous utilisez un nom d'hôte personnalisé

Si vous utilisez un nom d'hôte personnalisé, par exemple si vous modifiez votre fichier d'hôtes:

N'utilisez pas de nom d'hôte simple comme mysite, car s'il existe un domaine de premier niveau (TLD) qui porte le même nom (mysite), vous rencontrerez des problèmes. Et ce n'est pas très improbable: en 2020, il y a plus de 1 500 domaines de premier niveau, et la liste ne cesse de s'allonger. coffee, museum, travel et de nombreuses grandes entreprises (peut-être même celle de l'entreprise dans laquelle vous travaillez) sont des TLD. Cliquez ici pour consulter la liste complète.
N'utilisez que des domaines qui vous appartiennent ou qui sont réservés à cet effet. Si vous ne possédez pas votre propre domaine, vous pouvez utiliser test ou localhost (mysite.localhost). test ne fait l'objet d'aucun traitement particulier dans les navigateurs, mais localhost le fait: Chrome et Edge sont compatibles avec http://<name>.localhost dès la première utilisation, et il se comportera de manière sécurisée avec localhost. Essayez-le: exécutez n'importe quel site sur localhost et accédez à http://<whatever name you like>.localhost:<your port> dans Chrome ou Edge. Cela pourrait bientôt être possible également dans Firefox et Safari. Vous pouvez le faire (avec des sous-domaines tels que mysite.localhost), car localhost n'est pas seulement un nom d'hôte: il s'agit également d'un domaine de premier niveau complet, comme com.

En savoir plus

Nous vous remercions vivement pour vos contributions et vos commentaires à tous les évaluateurs, en particulier Ryan Sleevi, Filippo Valsorda, Milica Mihajlija, Rowan Merewood et Jake Archibald. 🙌

Image héros de @moses_lee sur Unsplash, modifiée.