Scanner de formulaires non sécurisés

Comment fonctionne cette vérification

Scanaris analyse le HTML de ta page principale et cherche des formulaires contenant un champ <input type="password"> : une connexion, une inscription, un changement de mot de passe. S'il n'y en a aucun, il ne fait rien. S'il y en a, il vérifie deux choses. Première : si la page elle-même a été servie en HTTP, il ouvre un constat de sévérité élevée, parce que tout ce que l'utilisateur tape voyage en clair. Seconde : si la page est en HTTPS mais que l'attribut action du formulaire commence par http://, il ouvre un autre constat de sévérité élevée avec cette URL, parce que l'envoi du mot de passe part non chiffré même si la page qui le demande était sûre. Seule la page analysée est examinée ; si ta connexion vit sur une autre route, analyse-la directement.

Pourquoi c'est important

Un mot de passe est la donnée la plus précieuse qu'un utilisateur te confie, et c'est celle que les connexions non chiffrées traitent le plus mal. Quand un formulaire voyage en HTTP, n'importe qui sur le chemin (le wifi d'un café, le fournisseur d'accès, un routeur compromis) lit l'identifiant et le mot de passe tels quels, sans aucune technique. Et comme la plupart des gens réutilisent leurs mots de passe, ce qui fuit n'est pas seulement l'accès à ton site. Les navigateurs le savent : Chrome et Firefox marquent en rouge tout champ de mot de passe sur une page HTTP et avertissent l'utilisateur que ce n'est « pas sécurisé », donc en plus d'un risque réel c'est une perte de confiance visible.

D'où ça vient

Le premier cas apparaît quand le site ne redirige pas HTTP vers HTTPS et que quelqu'un arrive par un vieux lien. Le second est presque toujours un action tapé à la main pendant le développement (http://localhost:3000/login ou http://api.mondomaine.com/auth) que personne n'a changé, ou un formulaire copié d'un exemple. Ça arrive aussi quand la connexion pointe vers un service externe qui n'a pas encore de certificat.

Comment corriger

• Sers tout le site en HTTPS et redirige HTTP. C'est la base de tout le reste ; la vérification redirection HTTPS te dit si tu l'as. Sur Vercel, Netlify ou Cloudflare c'est fait d'office ; sur ton propre serveur, un bloc de redirection dans nginx ou Apache.
• Change l'action en chemin relatif (action="/login"), qui hérite du protocole de la page, ou en URL complète avec https://. Si tu utilises un framework (Nuxt, Next.js, Laravel, Django), l'URL de l'API doit venir d'une variable d'environnement avec la valeur de production, pas être écrite dans le template.
• Si un tiers gère la connexion (Auth0, Supabase, Firebase, Clerk), son endpoint est déjà en HTTPS ; le constat pointe alors vers un action à toi qui n'a rien à faire là.
• Ajoute HSTS pour que le navigateur n'essaie plus jamais HTTP, pas même au premier saut ; HSTS faible le mesure.

Vérifie que c'est corrigé

curl -sI http://tondomaine.com/login | grep -iE "^(HTTP|location)"
curl -s https://tondomaine.com/login | grep -oE '<form[^>]*action="[^"]*"' 

La première doit renvoyer un 301 vers https://. Dans la seconde, aucun action ne peut commencer par http:// ; normalement tu vois des chemins relatifs ou rien (les formulaires sans action envoient vers la page elle-même).

Questions fréquentes

Mon formulaire envoie par JavaScript, pas par action. Suis-je concerné ?

Cette vérification regarde l'attribut action, donc un formulaire qui fait un fetch n'est pas signalé par cette voie. Mais le risque est le même si le fetch pointe vers http:// : sur une page HTTPS le navigateur le bloquera comme contenu mixte, et sur une page HTTP il voyagera en clair. Vérifie l'URL de l'API quand même.

C'est seulement un environnement de test sans vrais utilisateurs.

Alors ne l'analyse pas comme s'il était en production, ou accepte le constat. Mais attention aux environnements de test qui finissent dans Google : si quelqu'un y crée un compte avec son mot de passe habituel, le problème est réel.

Un champ de mot de passe sur une page HTTPS avec un action relatif, c'est bon ?

Oui. C'est la configuration correcte et elle ne génère aucun constat. Ce qu'il reste à regarder, c'est comment tu stockes ensuite la session : cookies non sécurisés et jeton dans le stockage couvrent cette partie.