Tester la sécurité de son site web : audit de la connexion, des permissions et de HTTPS

1. Suivre les protections le long d’un vrai parcours

Partez d’une tâche qui compte pour un visiteur : créer un compte, consulter une commande, envoyer une demande au support. Listez les pages, les services et les données qu’elle mobilise. La revue a ainsi un objectif concret, et le travail technique se rattache à un service que les utilisateurs emploient vraiment.

Chaque couche joue son rôle. Le réseau et le DNS mènent le visiteur aux bons services. L’application reconnaît le compte et applique les permissions. Le navigateur reçoit les contenus par une connexion chiffrée et suit les politiques envoyées dans les réponses. L’hébergement, le CDN et les dépendances logicielles soutiennent le tout en arrière-plan. Le guide de test de la sécurité web de l’OWASP (WSTG) propose une façon structurée d’explorer ces couches, de la collecte d’informations à la gestion des sessions. Suivre un parcours aide chaque spécialiste à voir comment son travail s’inscrit dans l’ensemble.

Fixez le périmètre avant de commencer : quels noms d’hôte, quels environnements (production, préproduction), quels comptes de test, et qui a donné son accord. Une revue se mène uniquement sur des sites que vous possédez ou que vous êtes autorisé à examiner ; mettre ce périmètre par écrit évite les malentendus avec l’hébergeur et les prestataires.

2. Relier chaque protection à un bénéfice concret

Ce tableau aide l’équipe à fixer les priorités. Un parcours de compte utilisé par de nombreux clients mérite souvent d’être examiné en premier. Un composant partagé, comme un gabarit de page, un module de connexion ou la configuration du serveur, est aussi un bon candidat : une correction qui y est appliquée profite à toutes les pages qui l’utilisent. Priorisez selon le parcours concerné et le nombre d’endroits qui en profitent.

3. Offrir une expérience de compte cohérente et sûre

L’authentification établit quel compte utilise le service ; l’autorisation détermine ensuite les actions et les données permises. Décrivez ces règles en langage courant : une cliente consulte ses propres factures, un agent du support traite les demandes qui lui sont attribuées, un administrateur gère les paramètres de l’équipe. Cette description devient un plan de test. Pour chaque règle, essayez aussi le cas inverse avec vos propres comptes de test, par exemple ouvrir la facture d’un autre compte en changeant l’identifiant dans l’URL : le serveur doit refuser, quoi qu’affiche l’interface.

Examinez l’inscription, la connexion, la vérification de l’adresse, la récupération et la déconnexion comme un seul parcours. Laissez fonctionner les gestionnaires de mots de passe, autorisez le collage dans les champs d’identifiant, de mot de passe et de code à usage unique, et donnez aux formulaires des libellés clairs. Quand l’authentification multifacteur convient au compte, proposez une activation et une récupération compréhensibles. Vérifiez que les messages d’erreur de connexion et de récupération restent génériques, sans révéler si une adresse possède un compte, et que les tentatives répétées sont freinées. Les recommandations d’authentification de l’OWASP détaillent ces contrôles. Testez avec des comptes dédiés qui représentent chaque rôle et des données d’exemple faciles à reconnaître.

4. Rendre les observations techniques faciles à partager

Une bonne revue consigne ce qui a été examiné et ce qui s’est passé : la page ou le service exact, la valeur observée dans la réponse, le comportement attendu et les étapes suivies. Utilisez des données d’exemple et masquez les mots de passe, jetons et autres secrets dans les notes partagées. Développeurs, support et futurs examinateurs disposent alors d’une référence commune.

Regroupez les observations par composant responsable. Plusieurs pages peuvent partager la même configuration de session, et plusieurs contrôles réseau décrire un seul service. Pour un site public, HTTPS utilise habituellement le port 443, et le port 80 sert surtout à rediriger vers l’adresse HTTPS. Le guide TLS de MDN recommande de rediriger vers la même ressource en HTTPS et, pour une API ou un site non destiné au public, de désactiver complètement HTTP. Documenter le rôle de chaque service accessible transforme une liste de détails techniques en carte compréhensible.

Gardez les contrôles réussis à côté des points à suivre : la revue montre ainsi les protections déjà en place. Hiérarchisez aussi avec mesure. Un en-tête Server ou X-Powered-By qui affiche une version gagne à être réduit ou retiré, mais le guide de test de l’OWASP rappelle qu’une information exposée sur le serveur n’est pas forcément une vulnérabilité en soi, et que la mise à jour du logiciel fait partie du remède. Selon MDN, maintenir le logiciel à jour est d’ailleurs une approche plus solide que masquer cet en-tête : c’est une mesure d’hygiène, pas une protection.

5. Intégrer les bonnes pratiques au développement courant

Appuyez-vous sur des composants d’authentification éprouvés, des requêtes de base de données paramétrées et des contrôles de permission côté serveur. Rangez les secrets, comme les clés d’API ou les mots de passe de base de données, dans un gestionnaire de secrets plutôt que dans le code, avec un responsable et une procédure de renouvellement.

Donnez aux cookies de session des attributs adaptés au parcours réel. Secure les réserve aux requêtes HTTPS. HttpOnly empêche les scripts de la page de les lire, mais le navigateur les envoie toujours avec les requêtes correspondantes et l’attribut ne chiffre rien : il n’empêche pas une faille XSS, il empêche seulement qu’un script injecté lise le cookie pour le réutiliser ailleurs. SameSite se fixe explicitement ; les recommandations de l’OWASP sur la gestion des sessions le présentent comme une défense en profondeur contre le CSRF, pas comme un remplaçant des jetons anti-CSRF. La référence OWASP sur les en-têtes HTTP explique comment ces réglages s’ajoutent aux politiques du navigateur, et l’ANSSI publie des recommandations pour la mise en œuvre d’un site web qui couvrent notamment HSTS, la CSP et la protection contre le détournement de clic.

Tenez un registre court des services : rôle, responsable, version du logiciel et méthode de mise à jour. Quand l’équipe ajoute un prestataire de paiement ou un widget de support, inscrivez-le au registre et rejouez le parcours concerné. Planifier les mises à jour et garder sous la main la dernière configuration qui fonctionnait simplifie la coordination et le retour en arrière. Un petit ensemble de pratiques appliquées de façon cohérente dans tous les gabarits donne à chacun une référence commune.

6. Installer un rythme de revue reproductible

Établissez une base de référence et répétez les mêmes contrôles après chaque changement pertinent. Gardez la même cible, les mêmes rôles et le même parcours pour que les comparaisons restent parlantes. Pour les permissions, confirmez que chaque compte de test obtient exactement l’accès prévu, ni plus ni moins. Pour les politiques du navigateur, repassez par les formulaires et les retours depuis des sites externes qu’utilisent les visiteurs.

1. Consignez les pages, les rôles et les actions inclus dans la revue.
2. Examinez les réponses reçues et notez la protection observée.
3. Déroulez le parcours prévu avec des comptes de test représentatifs.
4. Notez le résultat, la personne responsable et la prochaine occasion de revue.

Les bonnes occasions de revue sont un changement d’hébergement, d’authentification, de gabarits partagés ou de services connectés, mais aussi des échéances prévisibles comme le renouvellement d’un certificat, du nom de domaine ou d’une clé d’API. Un historique daté aide un nouveau collègue à comprendre le raisonnement derrière la configuration. Avec le temps, cette routine montre concrètement comment le site est entretenu et comment les actions importantes des clients sont protégées.

7. Commencer par une première revue modeste

Choisissez une page publique et une action de compte, puis décrivez leurs protections dans une courte liste de contrôle. Pour la partie publique, le snapshot gratuit de Sitelemetry exécute huit contrôles passifs sur l’origine du site, sans inscription : résolution DNS, politique e-mail (SPF, DMARC, CAA), certificat TLS, en-têtes de sécurité HTTP, posture de redirection HTTPS, signaux technologiques, cache, compression et CDN, et état du domaine (WHOIS). La redirection depuis HTTP n’est testée que si vous saisissez une adresse en http://. Ce n’est pas un test d’intrusion : il n’envoie aucun exploit, ne scanne pas les ports et ne tente aucune connexion à un compte ; il ne teste donc ni les comptes ni les permissions décrits plus haut. Il donne un score, une note de durcissement et jusqu’à trois signaux à examiner en premier.

Pour aller plus loin, le guide du certificat SSL/TLS et de HTTPS couvre la couche connexion, le guide pour vérifier les en-têtes de sécurité HTTP aide à lire et corriger ceux que votre site envoie, et le guide SPF, DKIM et DMARC traite la messagerie du domaine. Avant la mise en ligne d’un nouveau site ou une migration, la checklist de mise en ligne reprend ces réglages publics un par un. Pour un seul volet, le vérificateur d’en-têtes de sécurité gratuit évalue huit en-têtes clés sur la page d’accueil, et le vérificateur SPF et DMARC interroge les enregistrements de messagerie d’un domaine.