Comment vérifier les formulaires de votre site web : étiquettes, types de champ, HTTPS et CSRF

Formulaires de contact, d'inscription, de connexion ou de commande, champs de recherche : c'est là que votre site demande aux visiteurs d'agir. Un formulaire déroutant, pénible à remplir sur un téléphone ou non sécurisé vous coûte des prospects et de la confiance. Et les problèmes de formulaire restent le plus souvent invisibles jusqu'à ce que quelqu'un se plaigne, car ceux qui abandonnent ne vous préviennent pas.

La plupart des problèmes de formulaire se voient dans le HTML : on peut donc les vérifier sans rien remplir. Voici ce qu'il faut regarder.

Ergonomie et accessibilité

Chaque champ a besoin d'une étiquette

Chaque champ doit être associé à un <label> au moyen de for et id (ou être englobé par lui). Les lecteurs d'écran annoncent l'étiquette, et un clic dessus place le focus dans le champ. Un placeholder n'est pas une étiquette : il disparaît dès que l'on commence à saisir, il est souvent peu contrasté et il n'est pas annoncé de façon fiable. Si une maquette ne permet vraiment pas d'afficher une étiquette visible, aria-label sert de solution de repli, mais les étiquettes visibles aident tout le monde. Notre guide de l'accessibilité traite les étiquettes plus en détail.

Utilisez le bon type de champ

type="email", type="tel" et type="url" font apparaître le bon clavier sur téléphone et offrent une validation de base par le navigateur. Un champ de téléphone en type="text" oblige les visiteurs sur mobile à chercher les chiffres. Prudence avec type="number" : il est prévu pour les quantités, pas pour les numéros de téléphone, les numéros de carte ou les codes postaux.

Ajoutez des indications autocomplete

L'attribut autocomplete indique aux navigateurs et aux gestionnaires de mots de passe la nature de chaque champ : name, email, tel, street-address, postal-code, cc-number, current-password, new-password, one-time-code. Il permet aux visiteurs de remplir un formulaire d'un seul geste, et c'est une exigence des WCAG 2.1 (critère de succès 1.3.5) pour les champs qui recueillent des informations sur l'utilisateur. Ne mettez pas autocomplete="off" sur les champs de mot de passe : cela pousse les gens vers des mots de passe plus faibles et réutilisés.

Un vrai bouton d'envoi et une validation utile

Utilisez un <button type="submit"> pour que le formulaire fonctionne avec la touche Entrée et sans JavaScript sur mesure. Signalez les champs obligatoires avec l'attribut required et précisez-le dans l'étiquette, puis affichez les messages d'erreur à côté du champ, en termes simples. L'ajout de novalidate désactive les contrôles intégrés au navigateur ; ce n'est acceptable que si vous les remplacez par les vôtres.

Sécurité

• HTTPS pour la page et pour l'action. Un champ de mot de passe sur une page HTTP, ou un formulaire dont l'attribut action pointe vers une URL http://, transmet en clair ce que les gens saisissent. La page comme l'action doivent être en HTTPS.
• Jamais de GET pour les mots de passe. Avec method="get", les valeurs du formulaire se retrouvent dans l'URL, et de là dans l'historique du navigateur, les journaux du serveur et les en-têtes referrer. Utilisez method="post" pour toute donnée sensible.
• Protection CSRF. Les formulaires qui modifient quelque chose (connexion, mise à jour d'un compte, passage d'une commande) doivent être protégés contre la falsification de requête intersites (cross-site request forgery), généralement par un jeton secret placé dans un champ caché et vérifié par le serveur, complété par des cookies SameSite. Consultez comment vérifier la sécurité des cookies.
• Sachez où partent les données. Un formulaire envoyé vers un autre domaine, comme celui d'un prestataire de listes de diffusion ou de CRM, peut être normal. Assurez-vous toutefois que c'est voulu et couvert par votre politique de confidentialité.
• Validez côté serveur. La validation par le navigateur est une commodité pour les visiteurs de bonne foi ; n'importe qui peut la contourner. Le serveur doit vérifier de nouveau chaque valeur.

Comment Rudra vérifie les formulaires, sans les envoyer

Le vérificateur de liens cassés gratuit et l'audit de site web chargent votre page dans un vrai navigateur et examinent jusqu'à 10 des formulaires qu'elle contient. Ils signalent, en indiquant le nom des formulaires et des champs concernés :

• les champs de mot de passe sur une page HTTP, les formulaires envoyés vers http:// et les formulaires de mot de passe qui utilisent GET (chacun coûte 10 points) ;
• les champs dont la seule étiquette est un placeholder (3 points) ;
• les champs sans étiquette accessible, les types de champ qui ne correspondent pas au champ (un champ d'e-mail en type="text"), les indications autocomplete manquantes, autocomplete="off" sur les mots de passe, les formulaires envoyés vers un autre hôte, les formulaires sans bouton d'envoi, les champs d'e-mail ou de téléphone obligatoires sans contraintes, et novalidate : tous à titre informatif ;
• les formulaires POST dépourvus de jeton de type CSRF visible, avec un faible degré de confiance, car le jeton peut être ajouté par JavaScript ou le serveur peut protéger le formulaire d'une autre manière.

L'outil demande aussi au navigateur, une seule fois, s'il bloquerait l'envoi à vide des champs marqués comme obligatoires. Pour cela, il lit l'état de validation de chaque champ, sans y placer le focus ni rien remplir, et sans déclencher les gestionnaires de validation propres au site.

Pourquoi nous n'envoyons jamais de formulaire

L'envoi d'un formulaire a des effets bien réels : un e-mail arrive dans la boîte de réception de quelqu'un, un compte est créé, une commande ou un ticket d'assistance apparaît, une limite de requêtes ou un filtre antifraude se déclenche. Un outil automatisé n'a aucun moyen de savoir quels formulaires peuvent être envoyés sans risque : le nôtre n'en envoie donc aucun. Les formulaires ne sont jamais envoyés, cliqués, ciblés ni remplis, et les rapports ne contiennent que des noms de champ et des étiquettes, jamais de valeurs.

En contrepartie, certaines choses ne peuvent être testées qu'en envoyant un formulaire, et c'est à vous de vous en charger : l'envoi arrive-t-il à destination, à quoi ressemblent les messages de confirmation et d'erreur, le serveur rejette-t-il les saisies incorrectes ou intersites, et la protection antispam fonctionne-t-elle ?

Un test manuel pour chaque formulaire

1. Remplissez-le sur un téléphone et vérifiez que chaque champ fait apparaître le bon clavier et se remplit automatiquement de façon cohérente.
2. Remplissez-le au clavier seul, puis avec un lecteur d'écran comme NVDA ou VoiceOver.
3. Envoyez-le vide, puis avec une adresse e-mail erronée, et lisez les messages d'erreur.
4. Envoyez-le correctement et vérifiez que le message arrive là où il doit arriver.
5. Pour les formulaires de connexion et de compte, demandez à un développeur de confirmer la protection CSRF et la validation côté serveur.