JavaScript: validation côté client ou côté serveur
Quel est le meilleur pour faire la validation côté client ou côté serveur?
Dans notre situation, nous utilisons
- jQuery et MVC.
- Données JSON à transmettre entre notre vue et notre contrôleur.
Une grande partie de la validation que je fais consiste à valider des données lorsque les utilisateurs les saisissent. Par exemple, j'utilise l'événement keypress pour empêcher les lettres dans une zone de texte, pour définir un nombre maximal de caractères et la présence d'un nombre dans une plage.
Je suppose que la meilleure question serait: Y at-il des avantages à effectuer une validation côté serveur sur le côté client?
Awesome répond à tous. Le site Web que nous avons est protégé par mot de passe et pour une petite base d'utilisateurs (<50). Si ce n'est pas le cas, nous enverrons des ninjas. Mais si nous concevions un site pour tout le monde, j'accepterais de faire une validation des deux côtés.
Comme d'autres l'ont dit, vous devriez faire les deux. Voici pourquoi:
Côté client
Vous souhaitez d'abord valider les entrées côté client, car vous pouvez donner un meilleur retour à l'utilisateur moyen . Par exemple, s'ils entrent une adresse électronique invalide et passent au champ suivant, vous pouvez immédiatement afficher un message d'erreur. De cette façon, l'utilisateur peut corriger tous les champs avant il soumet le formulaire.
Si vous ne validez que sur le serveur, ils doivent soumettre le formulaire, obtenir un message d'erreur et tenter de résoudre le problème.
(Cette difficulté peut être soulagée en demandant au serveur de restituer le formulaire avec l'entrée originale de l'utilisateur renseignée, mais la validation côté client est toujours plus rapide.)
Du côté serveur
Vous souhaitez valider côté serveur car vous pouvez vous protéger contre l'utilisateur malveillant , qui peut facilement contourner votre JavaScript et soumettre des entrées dangereuses au serveur.
Il est très dangereux de faire confiance à votre interface utilisateur. Non seulement ils peuvent abuser de votre interface utilisateur, mais ils peuvent ne pas utiliser votre interface utilisateur du tout, ni même un navigateur . Que se passe-t-il si l'utilisateur modifie manuellement l'URL, ou exécute son propre Javascript, ou modifie ses demandes HTTP avec un autre outil? Que se passe-t-il s'ils envoient des requêtes HTTP personnalisées à partir de curl ou d'un script, par exemple?
( Ce n’est pas théorique; par exemple, j’ai travaillé sur un moteur de recherche de voyages qui a soumis à nouveau la recherche de l’utilisateur à de nombreuses compagnies aériennes partenaires, compagnies de bus, etc., en envoyant POST requêtes comme si l’utilisateur a rempli le formulaire de recherche de chaque entreprise, puis a rassemblé et trié tous les résultats. Le formulaire JS de ces entreprises n’a jamais été exécuté et il était essentiel pour nous de fournir des messages d’erreur dans le code HTML renvoyé. Bien sûr, une API aurait été Nice, mais c'était ce que nous devions faire.)
Ne pas permettre cela est non seulement naïf du point de vue de la sécurité, mais aussi non standard: un client doit être autorisé à envoyer HTTP via le moyen de son choix, et vous devez répondre correctement. Cela inclut la validation.
La validation côté serveur est également importante pour la compatibilité - JavaScript n'est pas activé pour tous les utilisateurs, même s'ils utilisent un navigateur.
Addendum - Décembre 2016
Certaines validations ne peuvent même pas être effectuées correctement dans le code de l'application côté serveur et sont tout à fait impossibles dans le code côté client , car elles dépendent sur l'état actuel de la base de données. Par exemple, "personne d'autre n'a enregistré ce nom d'utilisateur", ou "la publication de blog que vous commentez existe toujours", ou "aucune réservation existante ne chevauche les dates demandées", ou "le solde de votre compte est toujours suffisant pour couvrir cet achat. . " Seule la base de données peut valider de manière fiable des données qui dépendent de données connexes. Développeurs vissez régulièrement ce résultat , mais PostgreSQL fournit quelques bonnes solutions .
Oui, la validation côté client peut toujours être totalement ignorée. Vous devez faire les deux, côté client pour fournir une meilleure expérience utilisateur, et côté serveur pour être sûr que l'entrée que vous obtenez est réellement validée et pas seulement supposée être validée par le client.
Je vais juste le répéter, parce que c'est assez important:
toujours valider sur le serveur
et ajouter du JavaScript pour la réactivité de l'utilisateur.
L'avantage de la validation côté serveur par rapport à la validation côté client est que la validation côté client peut être ignorée/manipulée:
- L'utilisateur final pourrait avoir javascript désactivé
- Les données peuvent être envoyées directement sur votre serveur par une personne qui n’utilise même pas votre site, avec une application personnalisée conçue à cet effet.
- Une erreur Javascript sur votre page (causée par un certain nombre de choses) pourrait entraîner l'exécution de votre validation, mais pas de la totalité de celle-ci.
En bref - toujours, toujours valider toujours côté serveur et ensuite considérer la validation côté client comme un "extra" ajouté pour améliorer l'expérience de l'utilisateur final.
Vous devez toujours valider sur le serveur.
Avoir également une validation sur le client est agréable pour les utilisateurs, mais est tout à fait précaire.
Vous pouvez effectuer une validation côté serveur et renvoyer un objet JSON avec les résultats de validation pour chaque champ, en maintenant au minimum le code Javascript client (tout en affichant des résultats) tout en conservant une expérience conviviale sans avoir à vous répéter sur le client et sur le serveur.
Eh bien, je trouve encore un peu de place pour répondre.
En plus des réponses de Rob et Nathan, j'ajouterais qu'il est important d'avoir des validations côté client. Lorsque vous appliquez des validations sur vos formulaires Web, vous devez suivre ces instructions:
Côté client
- Vous devez utiliser des validations côté client afin de filtrer les demandes authentiques provenant d'utilisateurs authentiques sur votre site Web.
- La validation côté client doit être utilisée pour réduire les erreurs pouvant survenir lors du traitement côté serveur.
- La validation côté client doit être utilisée pour minimiser les allers-retours côté serveur, de manière à économiser la bande passante et les demandes par utilisateur.
Du côté serveur
- Vous NE DEVRIEZ PAS supposer que la validation effectuée avec succès du côté client est parfaite à 100%. Peu importe même si cela sert moins de 50 utilisateurs. Vous ne savez jamais lequel de vos utilisateurs/employés se transforme en "mal" et fait une activité préjudiciable en sachant que vous n'avez pas les validations nécessaires en place.
- Même s'il est parfait en termes de validation d'adresse électronique, de numéros de téléphone ou de vérification de certaines entrées valides, il peut contenir des données très préjudiciables. Qui doit être filtré côté serveur, peu importe si c'est correct ou incorrect.
- Si la validation côté client est ignorée, vos validations côté serveur servent à vous protéger de tout dommage potentiel causé à votre traitement côté serveur. Ces derniers temps, nous avons déjà entendu beaucoup d’histoires d’injections SQL et d’autres techniques qui pourraient être appliquées afin d’obtenir des avantages pervers.
Les deux types de validations jouent des rôles importants dans leur domaine respectif, mais le plus fort est celui du serveur. Si vous recevez 10 000 utilisateurs à un moment donné, vous finirez certainement par filtrer le nombre de demandes provenant de votre serveur Web. Si vous constatez qu'il y a une seule erreur, telle qu'une adresse électronique non valide, ils renvoient le formulaire à nouveau et demandent à votre utilisateur de le corriger, ce qui réduira définitivement les ressources de votre serveur et votre bande passante. Il vaut donc mieux appliquer la validation javascript. Si javascript est désactivé, votre validation côté serveur viendra à son secours et je parie que seuls quelques utilisateurs pourraient l'avoir désactivé par inadvertance, car 99,99% des sites Web utilisent javascript et qu'il est déjà activé par défaut dans tous les navigateurs modernes.
Le côté client doit utiliser une validation de base via types de saisie HTML5 et attributs de modèle et comme ceux-ci ne sont utilisés que pour les améliorations progressives afin d'améliorer l'expérience utilisateur (Même s'ils ne sont pas pris en charge sur < IE9 et safari, mais nous ne comptons pas sur eux). Mais la validation principale devrait avoir lieu côté serveur.
Je suggérerai de mettre en œuvre à la fois la validation client et serveur, cela sécurisera davantage le projet ...... si je dois en choisir un, je partirai avec une validation côté serveur.
Mise à jour du 23 juillet 2018: le lien suivant n'est plus accessible:
Vous pouvez trouver des informations pertinentes ici http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/
JavaScript peut être modifié au moment de l'exécution.
Je suggère de créer une structure de validation sur le serveur et de la partager avec le client.
Vous aurez besoin d'une logique de validation séparée aux deux extrémités, ex:
"required" attributs sur inputs côté client
field.length > 0 du côté serveur.
Cependant, l'utilisation de la même spécification de validation éliminera certaines redondances (et erreurs) de la validation en miroir aux deux extrémités.
Je suis tombé sur un lien intéressant qui fait la distinction entre erreurs grossières, systématiques et aléatoires.
Client-Side validation convient parfaitement à la prévention des erreurs grossières et aléatoires. Typiquement une longueur maximale pour la texture et l'entrée. Ne pas imiter la règle de validation côté serveur; fournissez votre propre règle de validation empirique (par exemple, 200 caractères côté client; n côté serveur, dicté par une règle de gestion stricte).
Server-side validation convient parfaitement à la prévention des erreurs systématiques; il va appliquer les règles commerciales.
Dans un projet auquel je participe, la validation est effectuée sur le serveur via des requêtes ajax. Sur le client, j'affiche les messages d'erreur en conséquence.
Lectures complémentaires: erreurs grossières, systématiques, aléatoires:
https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO
La validation des données côté client peut être utile pour une meilleure expérience utilisateur: par exemple, un utilisateur qui saisit incorrectement son adresse électronique ne devrait pas attendre que sa demande soit traitée par un serveur distant pour en savoir plus sur la faute de frappe qu'il a faite.
Néanmoins, comme un attaquant peut contourner la validation côté client (et peut même ne pas utiliser le navigateur du tout), la validation côté serveur est requise et doit constituer le véritable portail pour protéger votre backend contre les utilisateurs néfastes.