Protéger un site ou une seule page par mot de passe
Protéger un site par mot de passe
Protéger un site ou une page web par mot de passe (vraies options) | We.Inc
Protégez une page ou un site entier par mot de passe d'une façon qui fonctionne vraiment : Basic auth sur le serveur, mot de passe de page de votre hébergeur ou créateur de site, ou comptes membres, et pourquoi les protections uniquement en script échouent.
Une vraie vérification de mot de passe a lieu sur le serveur avant l'envoi de la page. Utilisez le réglage de mot de passe de page de votre hébergeur ou créateur de site, l'authentification HTTP Basic dans Apache ou Nginx, ou de vrais comptes membres. Une boîte de mot de passe écrite en JavaScript ne fait que masquer la page dans le navigateur ; le contenu arrive quand même et n'importe qui peut lire le code source.
Les façons de mettre un mot de passe sur un site
Option
Protège le contenu ?
Idéal pour
Mot de passe de page du créateur de site ou du CMS
Oui, vérifié par la plateforme
Une page privée pour un client ou un événement
Authentification HTTP Basic (Apache, Nginx)
Oui, en HTTPS
Un site de préproduction ou un dossier entier
Comptes membres
Oui, par personne
Les espaces privés payants ou durables
Invite JavaScript ou div masqué
Non
Rien d'important
Saisissez un nom d'utilisateur et un mot de passe pour voir l'en-tête Authorization exact qu'un navigateur envoie avec l'authentification Basic, et avec quelle facilité il redevient du texte en clair. Cela montre pourquoi la Basic auth ne doit fonctionner qu'en HTTPS. L'encodage se fait sur votre appareil ; rien n'est envoyé.
Décidez si un seul mot de passe partagé suffit ou si chaque personne a besoin de son propre identifiant.
Sur un créateur de site ou WordPress, cherchez d'abord un réglage de visibilité ou de mot de passe de page.
Sur votre propre serveur, ajoutez l'authentification Basic au dossier ou à l'emplacement, avec le fichier de mots de passe placé hors du dossier web public.
Vérifiez que le site impose HTTPS, puis testez dans une fenêtre de navigation privée.
Donnez à la Basic auth un mot de passe long que vous n'utilisez nulle part ailleurs, et changez-le quand le projet ou l'aperçu se termine.
Dans WordPress, les éditeurs et administrateurs peuvent voir les articles protégés par mot de passe dans l'écran de modification sans le mot de passe.
Une page protégée peut quand même afficher son titre. Ne mettez pas d'informations privées dans le titre de la page.
Demandez aussi aux moteurs de recherche de ne pas afficher une page privée avec une balise noindex, mais ne comptez jamais sur cela comme protection.
Questions fréquentes
Puis-je protéger une page par mot de passe uniquement en HTML ?
Non. Le HTML n'a aucun moyen de vérifier un mot de passe. Tout ce que vous mettez dans le fichier est téléchargé par chaque visiteur, la vérification doit donc se faire sur le serveur ou la plateforme.
L'authentification HTTP Basic est-elle sûre ?
Seulement en HTTPS. La RFC 7617 souligne que le mot de passe traverse le réseau en clair, car Base64 est un encodage et non un chiffrement, et indique que ce schéma ne doit pas protéger d'informations sensibles sans une couche comme HTTPS.
Comment protéger une page par mot de passe dans WordPress ?
Ouvrez la page ou l'article, réglez Visibilité sur Protégé par mot de passe, saisissez un mot de passe et mettez à jour. Les visiteurs voient le titre et une demande de mot de passe au lieu du contenu.
Puis-je protéger un site WordPress entier ?
La documentation de WordPress elle-même indique que masquer tout le site ne fait pas partie du cœur, et renvoie vers des plugins ou des règles serveur comme .htaccess.
Qu'affiche le navigateur pour la Basic auth ?
Le serveur répond par un 401 et un en-tête WWW-Authenticate. Le navigateur demande alors un nom d'utilisateur et un mot de passe et renvoie la requête avec un en-tête Authorization.
Pourquoi les protections uniquement en script échouent
Un tutoriel courant ajoute un prompt() et compare la réponse avec un mot de passe écrit dans le même script. Le navigateur a déjà téléchargé la page entière, et le mot de passe se trouve dans le code source pour quiconque l'affiche. Désactiver JavaScript contourne complètement la vérification.
Il en va de même pour le contenu masqué en CSS. Si les mots sont dans le HTML, ils sont publics.
Choisir parmi les vraies options
Pour une page que vous partagez avec un client, le mot de passe de page de votre créateur de site ou CMS est le choix sûr le plus rapide. Pour une copie de préproduction d'un site, la Basic auth sur le serveur garde l'ensemble privé, y compris vis-à-vis des robots des moteurs de recherche.
Quand différentes personnes ont besoin d'accès différents, ou que vous devrez retirer l'accès à quelqu'un plus tard, utilisez des comptes. Un mot de passe partagé ne peut pas être retiré à une seule personne sans être changé pour tout le monde.
Des configurations serveur qui protègent vraiment un dossier
Créez le fichier de mots de passe avec l'outil htpasswd fourni avec Apache (par exemple htpasswd -c /etc/apache2/.htpasswd client), et gardez-le hors du dossier web public.
Apache : .htaccess dans le dossier à protéger
Require valid-user laisse entrer toute personne listée dans le fichier de mots de passe.
Nginx : protéger un emplacement
Nginx lit le même format de fichier htpasswd. Rechargez Nginx après modification.
À ne pas faire : une protection en JavaScript
Présentée pour que vous puissiez la reconnaître. Le mot de passe et le contenu se trouvent tous deux dans le fichier que chaque visiteur télécharge.
Ce qu'envoie la Basic auth
Nom d'utilisateur
Mot de passe
Le nom d'utilisateur ne peut pas contenir de deux-points, car le deux-points le sépare du mot de passe.
En-tête que le navigateur envoie avec chaque requête
Décodé par quiconque voit la requête
Base64 n'est pas un chiffrement. Sans HTTPS, cet en-tête révèle le mot de passe.