HTTP Basic Authentication

Qu'est-ce que l'authentification HTTP Basic ?

L'authentification HTTP Basic est le mécanisme de contrôle d'accès le plus simple intégré au protocole HTTP. Elle est spécifiée par l'IETF dans la RFC 7617, publiée en septembre 2015 par Julian Reschke, qui remplace l'ancienne définition de la RFC 2617. Il ne s'agit ni d'un produit ni d'un service fourni par un éditeur : tous les serveurs web courants (Apache, Nginx, IIS, Caddy) et la plupart des frameworks la prennent en charge nativement. On la rencontre surtout sur les sites de préproduction, les espaces d'administration, les outils internes et les API.

Comment elle apparaît sur un site

Quand un visiteur demande une page protégée, le serveur répond avec un code 401 et un en-tête WWW-Authenticate : Basic, souvent accompagné d'un nom de domaine de protection (realm). Les outils de détection de technologies repèrent le mécanisme grâce à cet en-tête. Le navigateur affiche alors sa propre boîte de connexion. L'identifiant et le mot de passe sont réunis par deux-points, encodés en Base64 et transmis dans l'en-tête Authorization de chaque requête suivante. Aucun JavaScript n'est chargé et aucun domaine externe n'est contacté.

Cookies et données personnelles

L'authentification Basic n'utilise pas de cookie. Le navigateur garde les identifiants en mémoire pendant la session et les renvoie automatiquement, ce qui explique aussi l'absence de véritable déconnexion. Les données personnelles concernées sont l'identifiant, le mot de passe et l'adresse IP du visiteur, généralement inscrite dans les journaux d'accès du serveur. Le Base64 est un encodage, pas un chiffrement : quiconque intercepte une requête non chiffrée peut lire le mot de passe.

RGPD et consentement

Aucun consentement n'est nécessaire. Le mécanisme sert uniquement à donner accès à un utilisateur autorisé au service qu'il a demandé, ce qui relève de l'exemption « strictement nécessaire » de l'article 5(3) de la directive ePrivacy (article 82 de la loi Informatique et Libertés). Le traitement des identifiants et des journaux repose sur le contrat avec l'utilisateur ou sur l'intérêt légitime de l'éditeur à sécuriser l'accès. Le mécanisme n'envoie aucune donnée à un tiers ni hors de l'UE. L'obligation de sécurité de l'article 32 du RGPD reste applicable.

Bonnes pratiques

• Servez les zones protégées uniquement en HTTPS, jamais en HTTP simple.
• Stockez les mots de passe hachés sur le serveur (bcrypt ou Argon2 dans les fichiers htpasswd).
• Limitez la durée de conservation des journaux d'accès et mentionnez-les dans votre politique de confidentialité.
• Pour des comptes utilisateurs publics, préférez une connexion par session ou un fournisseur d'identité, et réservez l'authentification Basic aux accès internes ou temporaires.
• Ajoutez une limitation de débit ou un filtrage par IP contre les attaques par force brute.