Les 10 erreurs les plus courantes commises par les développeurs Web : un tutoriel pour les développeurs

Publié: 2022-03-11

Depuis que le terme World Wide Web a été inventé en 1990, le développement d'applications Web a évolué, passant de pages HTML statiques à des applications métier complexes et entièrement dynamiques.

Aujourd'hui, nous avons des milliers de ressources numériques et imprimées qui fournissent des instructions étape par étape sur le développement de toutes sortes d'applications Web différentes. Les environnements de développement sont suffisamment "intelligents" pour détecter et corriger de nombreuses erreurs avec lesquelles les premiers développeurs se sont régulièrement battus. Il existe même de nombreuses plates-formes de développement différentes qui transforment facilement de simples pages HTML statiques en applications hautement interactives.

Tous ces modèles, pratiques et plates-formes de développement partagent un terrain d'entente et sont tous sujets à des problèmes de développement Web similaires causés par la nature même des applications Web.

Le but de ces conseils de développement Web est de faire la lumière sur certaines des erreurs courantes commises à différentes étapes du processus de développement Web et de vous aider à devenir un meilleur développeur. J'ai abordé quelques sujets généraux communs à pratiquement tous les développeurs Web, tels que la validation, la sécurité, l'évolutivité et le référencement. Vous ne devriez bien sûr pas être lié par les exemples spécifiques que j'ai décrits dans ce guide, car ils sont répertoriés uniquement pour vous donner une idée des problèmes potentiels que vous pourriez rencontrer.

Erreur courante n° 1 : validation des entrées incomplète

La validation des entrées utilisateur côté client et côté serveur est tout simplement indispensable ! Nous connaissons tous le sage conseil "ne faites pas confiance aux entrées des utilisateurs" mais, néanmoins, les erreurs résultant de la validation se produisent trop souvent.

L'une des conséquences les plus courantes de cette erreur est l'injection SQL qui figure dans le Top 10 de l'OWASP année après année.

N'oubliez pas que la plupart des frameworks de développement frontaux fournissent des règles de validation prêtes à l'emploi qui sont incroyablement simples à utiliser. De plus, la plupart des principales plates-formes de développement back-end utilisent des annotations simples pour garantir que les données soumises respectent les règles attendues. La mise en œuvre de la validation peut prendre du temps, mais elle doit faire partie de votre pratique de codage standard et ne jamais être mise de côté.

Erreur courante n° 2 : authentification sans autorisation appropriée

Avant de poursuivre, assurons-nous que nous sommes alignés sur ces deux termes. Comme indiqué dans les 10 vulnérabilités de sécurité Web les plus courantes :

Authentification : Vérification qu'une personne est (ou du moins semble être) un utilisateur spécifique, puisqu'elle a correctement fourni ses identifiants de sécurité (mot de passe, réponses aux questions de sécurité, scan d'empreintes digitales, etc.).

Autorisation : confirmation qu'un utilisateur particulier a accès à une ressource spécifique ou est autorisé à effectuer une action particulière.

En d'autres termes, l'authentification consiste à savoir qui est une entité, tandis que l'autorisation consiste à savoir ce qu'une entité donnée peut faire.

Permettez-moi de démontrer ce problème avec un exemple :

Considérez que votre navigateur contient les informations utilisateur actuellement enregistrées dans un objet similaire au suivant :

 { username:'elvis', role:'singer', token:'123456789' }

Lors d'un changement de mot de passe, votre application effectue le POST :

 POST /changepassword/:username/:newpassword

Dans votre méthode /changepassword , vous vérifiez que l'utilisateur est connecté et que le jeton n'a pas expiré . Ensuite, vous trouvez le profil utilisateur basé sur le paramètre :username , et vous modifiez le mot de passe de votre utilisateur.

Ainsi, vous avez validé que votre utilisateur est bien connecté, puis vous avez exécuté sa requête en changeant ainsi son mot de passe. Le processus semble OK, non ? Malheureusement, la réponse est non!

À ce stade, il est important de vérifier que l'utilisateur exécutant l'action et l'utilisateur dont le mot de passe est modifié sont les mêmes. Toute information stockée sur le navigateur peut être falsifiée, et tout utilisateur avancé peut facilement mettre à jour le username:'elvis' en nom d' username:'Administrator' sans utiliser autre chose que les outils de navigateur intégrés.

Donc, dans ce cas, nous nous sommes juste occupés de l' Authentication en nous assurant que l'utilisateur a fourni des informations d'identification de sécurité. Nous pouvons même ajouter la validation que la méthode /changepassword ne peut être exécutée que par des utilisateurs Authenticated . Cependant, cela ne suffit toujours pas pour protéger vos utilisateurs des tentatives malveillantes.

Vous devez vous assurer de vérifier le demandeur réel et le contenu de la demande dans votre méthode /changepassword et de mettre en œuvre une Authorization appropriée de la demande en vous assurant que l'utilisateur ne peut modifier que ses données.

L' Authentication et Authorization sont les deux faces d'une même médaille. Ne les traitez jamais séparément.

Erreur courante n° 3 : pas prêt à évoluer

Dans le monde actuel du développement à grande vitesse, des accélérateurs de démarrage et de la portée mondiale instantanée des bonnes idées, avoir votre MVP (produit minimum viable) sur le marché dès que possible est un objectif commun pour de nombreuses entreprises.

Cependant, cette pression temporelle constante fait que même les bonnes équipes de développement Web négligent souvent certains problèmes. La mise à l'échelle est souvent l'une de ces choses que les équipes tiennent pour acquise. Le concept MVP est génial, mais poussez-le trop loin et vous aurez de sérieux problèmes. Malheureusement, sélectionner une base de données et un serveur Web évolutifs et séparer toutes les couches d'application sur des serveurs évolutifs indépendants ne suffit pas. Il y a de nombreux détails auxquels vous devez penser si vous souhaitez éviter de réécrire des parties importantes de votre application plus tard - ce qui devient un problème majeur de développement Web.

Par exemple, supposons que vous choisissiez de stocker les photos de profil téléchargées de vos utilisateurs directement sur un serveur Web. Il s'agit d'une solution parfaitement valable : les fichiers sont rapidement accessibles à l'application, les méthodes de gestion des fichiers sont disponibles sur chaque plate-forme de développement et vous pouvez même servir ces images en tant que contenu statique, ce qui signifie une charge minimale sur votre application.

Mais que se passe-t-il lorsque votre application se développe et que vous devez utiliser deux serveurs Web ou plus derrière un équilibreur de charge ? Même si vous avez bien mis à l'échelle le stockage de votre base de données, les serveurs d'état de session et les serveurs Web, l'évolutivité de votre application échoue à cause d'une chose simple comme les images de profil. Ainsi, vous devez implémenter une sorte de service de synchronisation de fichiers (qui aura un retard et provoquera des erreurs 404 temporaires) ou une autre solution de contournement pour vous assurer que les fichiers sont répartis sur vos serveurs Web.

Ce que vous deviez faire pour éviter le problème en premier lieu était simplement d'utiliser un emplacement de stockage de fichiers partagé, une base de données ou toute autre solution de stockage à distance. Cela aurait probablement coûté quelques heures de travail supplémentaires pour tout mettre en œuvre, mais cela en aurait valu la peine.

Erreur commune n° 4 : SEO erroné ou manquant

La cause première des meilleures pratiques de référencement incorrectes ou manquantes sur les sites Web est des "spécialistes du référencement" mal informés. De nombreux développeurs Web pensent qu'ils en savent suffisamment sur le référencement et que ce n'est pas particulièrement complexe, mais ce n'est tout simplement pas vrai. La maîtrise du référencement nécessite un temps considérable passé à rechercher les meilleures pratiques et les règles en constante évolution sur la façon dont Google, Bing et Yahoo indexent le Web. À moins d'expérimenter constamment et d'avoir un suivi + une analyse précis, vous n'êtes pas un spécialiste du référencement, et vous ne devriez pas prétendre en être un.

De plus, le référencement est trop souvent reporté comme une activité qui se fait à la fin. Cela se fait au prix fort de problèmes de développement Web. Le référencement n'est pas seulement lié à la définition d'un bon contenu, de balises, de mots-clés, de métadonnées, de balises alt d'image, d'un plan de site, etc. Il comprend également l'élimination du contenu en double, une architecture de site explorable, des temps de chargement efficaces, des liens de retour intelligents, etc.

Comme pour l'évolutivité, vous devriez penser au référencement dès le moment où vous commencez à créer votre application Web, ou vous pourriez constater que terminer votre projet de mise en œuvre du référencement signifie réécrire tout votre système.

Erreur courante n° 5 : Actions consommatrices de temps ou de processeur dans les gestionnaires de requêtes

L'un des meilleurs exemples de cette erreur est l'envoi d'un e-mail basé sur une action de l'utilisateur. Trop souvent, les développeurs pensent que passer un appel SMTP et envoyer un message directement depuis le gestionnaire de requêtes de l'utilisateur est la solution.

Supposons que vous ayez créé une librairie en ligne et que vous prévoyiez de commencer avec quelques centaines de commandes par jour. Dans le cadre de votre processus de prise de commande, vous envoyez des e-mails de confirmation chaque fois qu'un utilisateur publie une commande. Cela fonctionnera sans problème au début, mais que se passe-t-il lorsque vous faites évoluer votre système et que vous recevez soudainement des milliers de demandes d'envoi d'e-mails de confirmation ? Vous obtenez soit des délais d'expiration de connexion SMTP, soit un dépassement de quota, soit le temps de réponse de votre application se dégrade considérablement car il gère désormais les e-mails au lieu des utilisateurs.

Toute action consommant du temps ou du processeur doit être gérée par un processus externe pendant que vous publiez vos requêtes HTTP dès que possible. Dans ce cas, vous devez disposer d'un service de messagerie externe qui récupère les commandes et envoie des notifications.

Erreur courante n° 6 : ne pas optimiser l'utilisation de la bande passante

La plupart des développements et des tests ont lieu dans un environnement de réseau local. Ainsi, lorsque vous téléchargez 5 images d'arrière-plan de 3 Mo ou plus chacune, il se peut que vous n'identifiiez pas de problème avec la vitesse de connexion de 1 Gbit dans votre environnement de développement. Mais lorsque vos utilisateurs commencent à charger une page d'accueil de 15 Mo via des connexions 3G sur leurs smartphones, vous devez vous préparer à une liste de plaintes et de problèmes.

L'optimisation de votre utilisation de la bande passante pourrait vous donner une grande amélioration des performances, et pour obtenir cette amélioration, vous n'avez probablement besoin que de quelques astuces. Il y a peu de choses que beaucoup de bons développeurs Web font par défaut, notamment :

  1. Minification de tout le JavaScript
  2. Minification de tous les CSS
  3. Compression HTTP côté serveur
  4. Optimisation de la taille et de la résolution de l'image

Erreur courante n° 7 : Ne pas développer pour différentes tailles d'écran

Le design réactif a été un grand sujet ces dernières années. L'expansion des smartphones avec différentes résolutions d'écran a apporté de nombreuses nouvelles façons d'accéder au contenu en ligne, ce qui entraîne également une multitude de problèmes de développement Web. Le nombre de visites de sites Web provenant de smartphones et de tablettes augmente chaque jour, et cette tendance s'accélère.

Afin d'assurer une navigation et un accès transparents au contenu du site Web, vous devez permettre aux utilisateurs d'y accéder à partir de tous les types d'appareils.

Il existe de nombreux modèles et pratiques pour créer des applications Web réactives. Chaque plate-forme de développement a ses propres trucs et astuces, mais certains frameworks sont indépendants de la plate-forme. Le plus populaire est probablement Twitter Bootstrap. Il s'agit d'un framework HTML, CSS et JavaScript open source et gratuit qui a été adopté par toutes les principales plateformes de développement. Adhérez simplement aux modèles et pratiques Bootstrap lors de la création de votre application, et vous obtiendrez une application Web réactive sans aucun problème.

Erreur courante n° 8 : incompatibilité entre navigateurs

Le processus de développement est, dans la plupart des cas, soumis à une forte pression temporelle. Chaque application doit être publiée dès que possible et même les bons développeurs Web se concentrent souvent sur la fourniture de fonctionnalités plutôt que sur la conception. Indépendamment du fait que la plupart des développeurs ont installé Chrome, Firefox, IE, ils n'utilisent qu'un seul de ces 90% du temps. Il est courant d'utiliser un navigateur pendant le développement et dès que l'application est presque terminée, vous commencerez à la tester dans d'autres navigateurs. C'est parfaitement raisonnable, en supposant que vous disposiez de beaucoup de temps pour tester et résoudre les problèmes qui apparaissent à ce stade.

Cependant, certaines astuces de développement Web peuvent vous faire gagner un temps considérable lorsque votre application atteint la phase de test multi-navigateurs :

  1. Vous n'avez pas besoin de tester dans tous les navigateurs pendant le développement ; cela prend du temps et est inefficace. Cependant, cela ne signifie pas que vous ne pouvez pas changer de navigateur fréquemment. Utilisez un navigateur différent tous les deux jours et vous reconnaîtrez au moins les problèmes majeurs au début de la phase de développement.
  2. Soyez prudent lorsque vous utilisez des statistiques pour justifier de ne pas prendre en charge un navigateur. De nombreuses organisations tardent à adopter de nouveaux logiciels ou à les mettre à niveau. Des milliers d'utilisateurs qui y travaillent peuvent encore avoir besoin d'accéder à votre application et ils ne peuvent pas installer le dernier navigateur gratuit en raison de politiques internes de sécurité et d'entreprise.
  3. Évitez le code spécifique au navigateur. Dans la plupart des cas, il existe une solution élégante compatible avec tous les navigateurs.

Erreur courante n° 9 : ne pas planifier la portabilité

L'hypothèse est la mère de tous les problèmes ! En matière de portabilité, ce dicton est plus vrai que jamais. Combien de fois avez-vous rencontré des problèmes de développement Web tels que des chemins de fichiers codés en dur, des chaînes de connexion à la base de données ou des hypothèses selon lesquelles une certaine bibliothèque sera disponible sur le serveur ? Supposer que l'environnement de production correspondra à votre ordinateur de développement local est tout simplement faux.

La configuration idéale de l'application doit être sans maintenance :

  1. Assurez-vous que votre application peut évoluer et s'exécuter dans un environnement à plusieurs serveurs à charge équilibrée.
  2. Permettre une configuration simple et claire, éventuellement dans un seul fichier de configuration.
  3. Gérez les exceptions lorsque la configuration du serveur Web n'est pas celle attendue.

Erreur courante n° 10 : RESTful Anti Patterns

Les API RESTful ont pris leur place dans le développement Web et sont là pour rester. Presque toutes les applications Web ont implémenté une sorte de services REST, que ce soit pour un usage interne ou pour s'intégrer à un système externe. Mais nous voyons toujours des modèles RESTful brisés et des services qui ne respectent pas les pratiques attendues.

Deux des erreurs les plus courantes commises lors de l'écriture d'une API RESTful sont :

  1. Utilisation de mauvais verbes HTTP. Par exemple, en utilisant GET pour écrire des données. HTTP GET a été conçu pour être idempotent et sûr, ce qui signifie que peu importe le nombre de fois que vous appelez GET sur la même ressource, la réponse doit toujours être la même et aucun changement dans l'état de l'application ne doit se produire.

  2. N'envoie pas les codes d'état HTTP corrects. Le meilleur exemple de cette erreur est l'envoi de messages d'erreur avec le code de réponse 200.

     HTTP 200 OK { message:'there was an error' }

Vous ne devez envoyer HTTP 200 OK que lorsque la requête n'a pas généré d'erreur. En cas d'erreur, vous devez envoyer 400, 401, 500 ou tout autre code d'état approprié à l'erreur qui s'est produite.

Un aperçu détaillé des codes d'état HTTP standard peut être trouvé ici.

Emballer

Le développement Web est un terme extrêmement large qui peut légitimement englober le développement d'un site Web, d'un service Web ou d'une application Web complexe.

Le principal point à retenir de ce guide de développement Web est le rappel que vous devez toujours faire attention à l'authentification et à l'autorisation, planifier l'évolutivité et ne jamais présumer quoi que ce soit à la hâte - ou être prêt à faire face à une longue liste de problèmes de développement Web !