Protéger un répertoire par htpasswd

La protection Basic Auth par .htpasswd est la façon la plus simple et la plus robuste de mettre un répertoire entier derrière un mot de passe, côté serveur. Pas de plugin, pas de session applicative : Apache demande les identifiants avant même de servir la moindre ligne. C'est parfait pour une préprod, un back-office, une API interne ou une documentation que vous ne voulez pas exposer publiquement.

Quand l'utiliser

• Préprod / staging : empêcher clients, curieux et moteurs de visiter la recette d'un site.
• wp-admin WordPress : rajouter une barrière avant le formulaire de login (frein massif contre les attaques par force brute).
• Répertoire /api interne : endpoints admin ou techniques qu'on ne veut pas laisser ouverts au web.
• Documentation privée : extranet léger, spécifications, accès client limité.

Méthode 1 — via l'interface Plesk

La plus rapide si vous avez la main sur le Plesk Datacampus :

1. Ouvrez Websites & Domains, sélectionnez le domaine.
2. Cliquez sur Protected Directories (ou « Répertoires protégés par mot de passe »).
3. Add Protected Directory : saisissez le chemin à protéger, par exemple /preprod ou /wp-admin.
4. Dans le répertoire créé, Add User : nom d'utilisateur + mot de passe.

Plesk génère automatiquement le .htaccess et le .htpasswd associé, et les place au bon endroit. Vous n'avez rien à éditer à la main.

Méthode 2 — manuel en SSH

1. Générer le fichier .htpasswd

Depuis une session SSH sur votre hébergement :

htpasswd -c /var/www/vhosts/monsite.fr/private/.htpasswd monuser
# Saisir le mot de passe deux fois

Le -c crée le fichier. Pour ajouter un deuxième utilisateur sans écraser le premier, omettez le -c :

htpasswd /var/www/vhosts/monsite.fr/private/.htpasswd autreuser

openssl passwd -apr1
# Saisir le mot de passe, copier le hash produit
echo 'monuser:$apr1$xxxxxxxx$yyyyyyyyyyyy' >> /var/www/vhosts/monsite.fr/private/.htpasswd

2. Stocker le fichier hors du webroot

Idéalement le .htpasswd n'est pas accessible depuis le web. Sur nos Plesk, un bon emplacement est un sous-dossier private/ à côté du httpdocs/ du site :

/var/www/vhosts/monsite.fr/
├── httpdocs/          # webroot, public
└── private/
    └── .htpasswd      # hors du webroot

Si ce n'est pas possible, placez-le à la racine du site et bloquez l'accès dans le .htaccess : <Files ".htpasswd"> Require all denied </Files>.

3. Créer le .htaccess qui va bien

Dans le répertoire à protéger, un .htaccess minimal :

AuthType Basic
AuthName "Zone protégée"
AuthUserFile /var/www/vhosts/monsite.fr/private/.htpasswd
Require valid-user

AuthName est le texte affiché dans la popup du navigateur. Require valid-user accepte tous les utilisateurs listés dans le .htpasswd. Pour n'autoriser qu'un seul nom : Require user monuser.

Protéger wp-admin sans casser les plugins

Si vous mettez bêtement un htpasswd sur /wp-admin, vous cassez admin-ajax.php que le front-end WordPress appelle pour plein de plugins (panier, filtres, formulaires…). Whitelistez-le explicitement :

AuthType Basic
AuthName "wp-admin"
AuthUserFile /var/www/vhosts/monsite.fr/private/.htpasswd
Require valid-user

<Files "admin-ajax.php">
    Satisfy Any
    Order allow,deny
    Allow from all
</Files>

Le bloc <Files> désactive l'auth sur ce fichier précis. Le reste de wp-admin reste verrouillé.

Protéger toute une préprod WordPress

En phase de refonte, vous voulez que ni les visiteurs, ni Google ne tombent sur la préprod. La combinaison gagnante :

1. Un .htpasswd à la racine de la préprod (protège tout, y compris la home).
2. Un robots.txt avec :

   User-agent: *
   Disallow: /

3. Dans WordPress, cocher Réglages > Lecture > Demander aux moteurs de recherche de ne pas indexer ce site.

Alternative : whitelist IP sans mot de passe

Si toutes les personnes concernées ont une IP publique fixe (bureau, VPN d'entreprise), vous pouvez remplacer le mot de passe par un filtre IP. Plus simple, rien à mémoriser :

Require ip 203.0.113.42
Require ip 2001:db8::/32

Et pour combiner htpasswd ou IP whitelist (l'un suffit) :

AuthType Basic
AuthName "Zone protégée"
AuthUserFile /var/www/vhosts/monsite.fr/private/.htpasswd

<RequireAny>
    Require valid-user
    Require ip 203.0.113.42
</RequireAny>

Bonnes pratiques sécurité

• Bcrypt plutôt que MD5/APR1 : sur Apache 2.4+, générez le hash avec -B pour forcer bcrypt :

  htpasswd -B -c /var/www/vhosts/monsite.fr/private/.htpasswd monuser

• Toujours en HTTPS. La Basic Auth envoie le couple identifiants en Base64 à chaque requête — en HTTP clair, c'est équivalent à publier son mot de passe. Nos hébergements forcent HTTPS par défaut, vérifiez que c'est bien le cas.
• Mots de passe sérieux. Pas de admin/admin, pas de preprod/preprod. Générez 16+ caractères aléatoires.
• Rotation. À la mise en prod, à un départ de prestataire, ou tous les 6 mois sur un back-office permanent.

Tester rapidement

Depuis un terminal, sans passer par le navigateur (qui met en cache les identifiants) :

# Sans identifiants : doit renvoyer 401
curl -I https://monsite.fr/preprod/

# Avec identifiants : doit renvoyer 200 (ou 301/302)
curl -I -u monuser:monmotdepasse https://monsite.fr/preprod/

Un 401 Unauthorized sans identifiants et un 200 OK avec : c'est en place.