Cinq questions à se poser avant de créer un projet Web

Il existe un million de raisons pour lesquelles les projets technologiques échouent. Des modèles commerciaux mal calculés, une demande surestimée ou des coûts bouillonnants, etc. Mais au cours de ma vie professionnelle, j'ai vu pas mal de projets dotés d'idées brillantes et d'un bon potentiel s'effondrer à cause d'erreurs et d'oublis apparemment mineurs. Et je pense que cette raison est la plus amère de toutes, du moins pour moi en tant que développeur. Dans cet article, je souhaite partager mon expérience et analyser les problèmes et les défis auxquels les développeurs backend sont confrontés en travaillant dans les applications Web. Je soulignerai les points clés qui sont souvent négligés et expliquerai comment surmonter ces obstacles avec une efficacité maximale. Je suis sûr que cela vous aidera à minimiser les risques et à augmenter considérablement les chances de réussite de votre projet.

1. Y a-t-il des secrets stockés dans votre code ?

Aussi évident que cela puisse paraître, ce point est crucial : ne stockez jamais d’informations confidentielles ou sensibles dans votre code source. Les violations peuvent entraîner des pertes financières et d’autres problèmes graves. Les informations sensibles qui ne doivent jamais être stockées dans le code comprennent :

• Clés API et jetons d'accès aux services internes ou externes
• Mots de passe et données de compte, y compris les mots de passe de la base de données et du système d'administration
• Clés de chiffrement
• Fichiers de configuration avec des données sensibles
• Réponses aux questions de sécurité comme le nom de jeune fille de la mère ou le nom de l'animal

Au lieu de stocker ces informations dans le code de votre projet, utilisez des variables d'environnement. Pour des systèmes plus sécurisés, envisagez d'utiliser des solutions de stockage secrètes robustes telles que Coffre HashiCorp . Gestionnaire de secrets AWS ou Secrets de GitHub peut aussi être utile. Le choix des outils de stockage secret dépend de facteurs tels que le type et la taille du projet, l'expérience de l'équipe et la pile technologique.

Si vous pensez que le stockage d'informations sensibles dans le code d'une application n'est pas un problème sérieux, considérez ceci : rien qu'en 2022, GitHub a détecté plus de 1,7 million de secrets potentiels exposés dans des référentiels publics. Imaginez combien de données de ce type pourraient exister dans des projets privés où les développeurs ne sont pas conscients des fuites potentielles jusqu'à ce qu'elles se produisent.

Solution : Vérifiez votre projet dès maintenant

Si vous avez déjà un projet et que vous vous inquiétez maintenant des secrets de votre code, il existe des solutions pratiques qui peuvent vous apporter une tranquillité d'esprit. Les vérifications manuelles peuvent prendre beaucoup de temps, c'est pourquoi l'automatisation est essentielle. Les outils utiles incluent :

• TruffeHog : recherche les secrets dans les référentiels Git en analysant l'historique des validations pour les clés API et autres données sensibles.
• GitLeaks : Détecte les secrets codés en dur tels que les mots de passe, les clés API et les jetons dans les référentiels git.
• GitGuardien : fonctionne dans votre environnement local ou CI pour trouver plus de 350 types de secrets et autres vulnérabilités de sécurité.
• Sécurité avancée de GitHub : analyse automatiquement les référentiels à la recherche de types de secrets connus et vous avertit si des secrets sont trouvés.

Ces outils ne sont que quelques exemples ; d'autres options populaires incluent SonarQube et Checkmarx . Tous deux proposent des solutions payantes et gratuites pour répondre à divers besoins et budgets. Le but ici n’est pas de lister tous les outils disponibles, mais de mettre en évidence l’existence de ces problèmes et leurs solutions potentielles. Reconnaître le problème représente la moitié de la bataille. Désormais, il est important de consacrer du temps pour y remédier et de choisir les outils adaptés à vos besoins.

2. Que savez-vous de vos licences de bibliothèque ?

Étonnamment, ce sujet est rarement abordé et certains développeurs ne se rendent même pas compte que l'utilisation de solutions tierces peut entraîner des problèmes juridiques et des problèmes importants pour leur entreprise. Vous ne me croyez pas ? Imaginez ce scénario : un développeur dans une petite entreprise inclut une bibliothèque distribuée sous le Licence publique générale GNU Affero (AGPL) dans un produit Web commercial. En tant que licence copyleft, AGPL exige que tout logiciel utilisant le code publié sous cette licence soit distribué selon les mêmes conditions. Cela signifie que tout le code de votre application Web, y compris les développements uniques, doit être ouvert et disponible pour une utilisation et une modification gratuites. Étant donné que notre exemple de produit est commercial, rendre son code source disponible pourrait gravement compromettre l'avantage concurrentiel et le modèle économique de l'entreprise.

De sérieux problèmes peuvent également survenir avec les projets utilisant des bibliothèques dont les licences interdisent explicitement toute utilisation commerciale. Et cela ne va pas beaucoup mieux s’il n’y a pas de licence du tout : en fait, l’absence de licence pose un problème important puisque tout code est protégé par droit d’auteur par défaut. Les licences accordent aux utilisateurs le droit d'utiliser le code dans des conditions spécifiques, mais sans licence, il n'existe aucune base légale pour utiliser le code, même s'il est accessible au public.

Il convient de noter que les problèmes de licence peuvent vous affecter de différentes manières selon votre juridiction : cette question est particulièrement pertinente pour les pays qui ont signé des accords internationaux sur le droit d'auteur. Par exemple, la Convention de Berne pour la protection des œuvres littéraires et artistiques, l'un des principaux traités internationaux dans ce domaine, compte actuellement environ 180 pays membres. Par conséquent, utiliser du code sans autorisation explicite signifierait une violation des lois sur le droit d’auteur et pourrait conduire à des batailles juridiques dans de nombreux endroits du monde. Cependant, cela ne signifie pas que vous devriez déménager dans un pays « confortable » simplement pour violer toutes les règles écrites et non écrites. Respectons-nous les uns les autres, et si quelqu'un ne veut pas que son développement soit utilisé à certaines fins, il est préférable de ne pas le faire, même d'un point de vue humain.

Solution : utiliser des vérifications et des mises à jour automatisées

Comme vous pouvez le constater, les questions de licences et de droits d’auteur sont complexes. Pour vous protéger, vous et votre entreprise, à l'avance, il est préférable de vérifier les licences des bibliothèques et des logiciels que vous utilisez. Pour les bibliothèques, ce n'est pas trop difficile ; les gestionnaires de paquets modernes disposent déjà d'outils pour cela. Par exemple, dans PHP composer, vous pouvez le faire avec la commande ` licences de compositeur `, en Python pip via ` licences pip `, et dans Golang, vous pouvez obtenir ces informations via ` aller-licences `.

Et n'oubliez pas d'appeler ces commandes lorsque vous mettez à jour les dépendances (c'est encore mieux d'automatiser ces vérifications), car la licence d'une bibliothèque connectée peut changer dans les nouvelles versions.

3. L'accès à votre version de développement est-il restreint ?

Dans le développement Web, il est courant d'avoir plusieurs versions d'un projet, telles que le développement (dev), l'assurance qualité (QA), la préparation et la production. J'ai fréquemment rencontré des scénarios dans lesquels les versions de développement/QA et de préparation d'un site ou d'un projet Web étaient accessibles à tous sur Internet. Il est alarmant de constater que les versions de test peuvent parfois être indexées par les moteurs de recherche plus efficacement que la version principale, ce qui nuit généralement au produit.

Le principal problème ici est que les versions de test peuvent contenir des bugs ou des informations sensibles, voire compromettantes. De plus, les versions bêta sont généralement plus vulnérables au piratage que la production finale. Cela signifie que leur disponibilité augmente le risque qu'un attaquant accède aux données sensibles, au code interne ou même au serveur lui-même. Cela est particulièrement vrai si vous développez un backend pour quelque chose comme une application mobile, car un accès non autorisé aux versions de test de l'API peut être extrêmement dangereux.

Au-delà des risques de sécurité, les pages Web en double peuvent avoir un impact négatif sur le classement des moteurs de recherche. Les moteurs de recherche comme Google peuvent considérer ces doublons comme du contenu indésirable, réduisant potentiellement le classement des pages originales de votre projet, voire les supprimant complètement de l'index.

Solution : élaborez votre stratégie de sécurité dès le départ

Ne lésinez pas sur les domaines. Si vous avez besoin d'une version de test accessible en ligne, achetez un domaine distinct spécialement pour celle-ci. Cette mesure simple mais efficace réduit les risques de sécurité, car les attaquants vérifient généralement d'abord les sous-domaines. Héberger votre version de test sur n’importe quel sous-domaine de la ressource principale en fait une cible facile.

Restreindre l'accès à toutes les versions de test. Assurez-vous que les versions de développement, d'assurance qualité, de préparation et autres ne sont pas accessibles au public. Configurez-les pour qu'ils soient accessibles uniquement via un VPN, par exemple. Cela réduit la probabilité d'un accès non autorisé, même si le domaine de test est connu d'acteurs malveillants.

Protégez les versions de test contre l’indexation. Même si vos versions de test ne sont accessibles que via VPN et hébergées sur des domaines secrets distincts, protégez-les de l'indexation des moteurs de recherche à l'aide d'un fichier « robots.txt » ou de balises méta « noindex ». Cette étape est cruciale, car les moteurs de recherche peuvent parfois trouver et indexer ces pages de manière inattendue.

4. Votre véritable adresse IP est-elle cachée ? Vos ports inutilisés sont-ils fermés ?

Il existe des règles de sécurité que de nombreux développeurs ont tendance à négliger, même si elles sont d'une importance cruciale et ont été établies grâce à des leçons durement apprises. L'une de ces règles consiste à toujours masquer la véritable adresse IP de votre projet. Si l'adresse IP de vos serveurs peut être déterminée via le nom de domaine, cela peut entraîner plusieurs problèmes tels que :

• Attaques DDoS : connaissant la véritable adresse IP de votre projet, les attaquants peuvent lancer une attaque par déni de service distribué (DDoS) sur votre serveur. Par exemple, un Amplification de réflexion DNS Une attaque pourrait submerger votre serveur avec un volume massif de réponses provenant de serveurs DNS publics, rendant votre service indisponible pour les utilisateurs et entraînant des pertes financières importantes.

  
  

• Identification des vulnérabilités potentielles : les pirates informatiques sérieux, et pas seulement les amateurs, peuvent analyser les ports ouverts et les logiciels exposés au réseau pour trouver et exploiter les faiblesses. Même des services bien connus comme MongoDB ont subi d'importantes violations de données en raison d'une mauvaise configuration. Bon nombre de ces problèmes pourraient être évités en masquant simplement la véritable adresse IP.

Solution : rendre la vie des attaquants potentiels plus compliquée

En masquant la véritable adresse IP de votre serveur, vous compliquez la tâche des attaquants qui souhaitent cibler votre système. L’utilisation d’un réseau de diffusion de contenu (CDN) ou de services de protection DDoS peut s’avérer très efficace ici. Les options populaires incluent CloudFlare , qui offre gratuitement des fonctionnalités CDN et une protection DDoS, ainsi que des services tels que Imperva (anciennement Incapsula) offrant des fonctions similaires et Qrateur , spécialisé dans la protection des applications Web avec un pare-feu d'applications Web, mais cela peut entraîner des coûts.

Bien que ces outils puissent améliorer considérablement la sécurité, il y a des considérations supplémentaires à garder à l’esprit :

• Fuite IP des en-têtes de courrier électronique : si vous utilisez votre serveur principal pour envoyer des e-mails, la véritable adresse IP peut être exposée dans les en-têtes de courrier électronique, réduisant ainsi à néant vos efforts de sécurité.

  
  

• Historique IP et requêtes Whois : services tels que Historique DNS ou Demande Whois peut révéler les adresses IP historiques associées à un domaine. Si votre véritable adresse IP a déjà été liée à votre domaine de travail, vous devez la modifier.

  
  

• Protection DDoS et points de terminaison d'API : soyez prudent lorsque vous utilisez la protection DDoS pour les domaines servant de points de terminaison d'API. Les systèmes de protection peuvent introduire des étapes de vérification des utilisateurs susceptibles de perturber le fonctionnement de vos applications côté client en remplaçant les réponses JSON/XML par du code HTML.

  
  

• Requêtes d'API sortantes : lorsque votre serveur envoie des requêtes à des API tierces, il peut révéler par inadvertance son adresse IP. L'utilisation de serveurs proxy pour de telles requêtes peut s'avérer utile, car il est plus facile de changer de proxy que de gérer les conséquences d'une attaque.

Il est important de se rappeler que cacher la véritable adresse IP de votre projet n’est pas une panacée. La fermeture des ports utilisés par votre logiciel depuis le réseau externe est cruciale dans la mesure du possible. Changer les ports standards est une pratique discutable ; certains experts affirment que cela complique votre configuration sans apporter d’avantages significatifs. Souvent, il est préférable de configurer le logiciel pour qu'il interagisse via des sockets Unix plutôt que des connexions réseau TCP (si votre projet et le logiciel s'exécutent sur le même serveur). Cette approche augmente non seulement la vitesse d'interaction, mais améliore également la sécurité en éliminant le besoin de ports ouverts.

Pour les systèmes de gestion de bases de données (SGBD) ou d'autres services internes sur des serveurs distincts, assurez-vous que l'accès est limité à des adresses IP spécifiques que vous contrôlez strictement. Cette configuration empêche tout accès non autorisé aux systèmes critiques, ajoute une couche de sécurité supplémentaire et minimise les risques d'attaques externes et de fuites de données.

5. Mettez-vous à jour les dépendances et les logiciels du projet ?

Ce conseil est assez simple mais, encore une fois, souvent négligé : mettez régulièrement à jour les dépendances et les logiciels serveur de votre projet. Un code obsolète et vulnérable est un rêve pour les attaquants qui peuvent facilement l'exploiter.

Solution : Automatisez vos mises à jour

Vous n'avez pas besoin de tout mettre à jour manuellement ; de nombreux outils d’automatisation peuvent vous aider. Par exemple, Dépendabot sur GitHub détecte automatiquement les dépendances obsolètes ou vulnérables et suggère des mises à jour.

L’automatisation du renouvellement des certificats de sécurité est également cruciale. Si tu utilises Chiffrons certificats, vous pouvez automatiser leur renouvellement avec Bot certifié . Les certificats expirés peuvent être très pénibles, mais automatiser leur renouvellement est une tâche simple.

\Le même principe s'applique aux logiciels serveur. Si vous travaillez avec Linux, en particulier les distributions basées sur Debian/Ubuntu, Mises à niveau sans surveillance peut facilement gérer la tâche. Pour les projets plus importants comportant de nombreux serveurs, des outils tels que Ansible , Chef , Fantoche , ou Sel sont disponibles.

Dernières pensées

Les conseils fournis ici ne représentent qu’une fraction de ce que les développeurs back-end doivent retenir. J'ai choisi de mettre en évidence des sujets cruciaux mais moins fréquemment abordés par rapport aux sujets courants comme Injection SQL ou CSRF attaques.

Pour une compréhension plus approfondie de la sécurité des applications Web, envisagez d'explorer le Fondation OWASP , une organisation à but non lucratif offrant des ressources précieuses. Le OWASP Top 10 Ce document, disponible sur leur site Web, répertorie les risques de sécurité des applications Web les plus courants et les plus critiques. Vous trouverez également des informations sur des attaques moins connues mais tout aussi dangereuses.

Je pense que la communauté des développeurs doit être à la fois compétente et solidaire dans le partage d'idées et d'expériences. J’invite donc chacun à partager ses observations et commentaires, qui sont précieux pour tous ceux qui travaillent dans le développement backend !