La validation des entrées côté client (JavaScript) rend-elle votre application sécurisée ?
Réponse courte
Non. La validation côté client est un pur confort d'usage — un attaquant peut désactiver JavaScript, modifier la requête dans le navigateur ou Burp, ou appeler votre API directement avec curl, ce qui la contourne totalement. Les contrôles de sécurité (validation, autorisation, assainissement) doivent s'imposer sur le serveur, le seul endroit que vous maîtrisez. L'erreur est de prendre le navigateur pour une frontière de confiance ; il ne l'est pas, car le client tourne sur la machine de l'attaquant. Les contrôles côté client sont parfaits pour un retour rapide, jamais pour la sécurité.
Cette question sépare les développeurs qui comprennent où réside la confiance de ceux qui supposent que le navigateur applique leurs règles. C'est l'une des idées fausses les plus courantes — et les plus dangereuses — chez les débutants en sécurité web.
Pourquoi la réponse populaire est fausse
Il semble intuitif que si le formulaire refuse une mauvaise entrée, celle-ci n'atteint jamais le serveur. Mais le navigateur n'est pas sous votre contrôle — il s'exécute sur la machine de l'attaquant. JavaScript peut être désactivé, des points d'arrêt posés, le DOM modifié et les attributs maxlength supprimés en une seconde. Plus fondamentalement, le navigateur est facultatif : un attaquant peut l'ignorer totalement et envoyer une requête HTTP brute avec curl, Postman ou un proxy d'interception comme Burp Suite. Aucun de vos contrôles front-end ne s'exécute alors. Obscurcir ou minifier le JavaScript ne change rien — la requête circule toujours sur le réseau où elle peut être réécrite, et désactiver les outils de développement ou le menu clic droit se contourne trivialement.
La frontière de confiance
La sécurité doit s'imposer à une frontière de confiance que vous maîtrisez réellement : le serveur. Tout ce qui arrive du client est non fiable par définition. Donc validation, autorisation et assainissement relèvent du serveur. La validation côté client reste utile — elle offre un retour instantané, réduit les allers-retours et améliore l'UX — mais c'est une fonctionnalité d'ergonomie, pas un contrôle de sécurité.
Que faire à la place
Reproduisez chaque règle client sur le serveur, et ajoutez les contrôles que le client ne peut garantir : validation de type et de plage, filtrage par liste blanche, limites de longueur, autorisation (cet utilisateur possède-t-il cet enregistrement ?) et encodage de sortie contextuel pour bloquer le XSS. Les frameworks et l'OWASP ASVS résument cela par « ne jamais faire confiance au client ». Bon modèle mental : supposez votre API publique et appelée directement par des attaquants, puis demandez-vous si chaque endpoint reste sûr. Si oui, votre validation est au bon endroit.
Questions de suivi probables
- Si la validation client sert l'UX, que doit faire le serveur avec les mêmes règles ?
- Comment contourner en pratique un champ 'maxlength' et une regex de vérification d'e-mail ?
- Où se place la validation des entrées par rapport à l'encodage de sortie et à l'autorisation ?