Vous dites que vous n'avez pas le choix, mais ce n'est pas vrai. Vous pouvez écrire vous-même tout le code dont vous avez besoin. Ou vous pouvez payer un professionnel de confiance pour écrire le code pour vous. Ou vous pouvez payer une société de sécurité pour auditer le code avant de l'utiliser. Ou vous pouvez accepter le risque et mettre en œuvre d'autres contrôles de sécurité pour atténuer les risques. Par exemple, si vous craignez que du code ne soit vulnérable à l'injection SQL, vous pouvez configurer un WAF (Web Application Firewall) devant lui.

La sécurité a un coût: temps, ressources, expertise, argent. Il n'y a pas de repas gratuit. Si vous ne pouvez pas vous le permettre, vous devrez soit éviter le problème (repenser votre projet), soit le déléguer (quelqu'un d'autre s'en chargera), soit l'atténuer (par exemple avec une défense en profondeur) ou simplement accepter le risque d'être piraté.

Personnellement, dans votre cas, lorsque vous avez affaire à du code qui n'est pas largement utilisé, si la bibliothèque n'est pas trop grande, j'essaierais de lire le code, à au moins pour vérifier s'il y a une "odeur de code". Même si vous ne vérifiez pas toute la logique, il est facile de vérifier s'il y a suffisamment de commentaires, s'ils ont du sens, si le code est propre et compréhensible, si certaines fonctions sont utilisées selon les meilleures pratiques, s'il y a des vérifications sur le les données d'entrée, etc. Le risque d'un code utilisé par quelques personnes et maintenu par seulement quelques développeurs est également qu'il puisse cesser d'être maintenu, ou que la maintenance s'avère de toute façon trop lente, donc à la fin de la journée, vous pourriez être obligé de lire et de comprendre le code de toute façon, de réparer votre application.Ensuite, si possible, j'essaierais également d'implémenter quelque chose pour une défense en profondeur, bien que configurer correctement un WAF ne soit pas facile, si vous voulez vraiment qu'il soit en même temps, évitez de casser votre application à cause de faux positifs.

Je vais d'abord aborder la partie générique de votre question, puis la partie PHP spécifique.

1. Ne faites pas confiance aux bibliothèques PHP obscures que personne n'utilise!

   C'est juste la question habituelle du gain / risque. Si le risque est faible, vous pouvez tout faire et utiliser des bibliothèques obscures (voire cassées). Cela signifie que ni la plate-forme ni le résultat de l'application finale ne sont essentiels à la mission. Si cela échoue à un moment donné, il vous suffira de produire un correctif ou de trouver une solution de contournement.

   Si vous voulez inclure la bibliothèque dans une application à valeur ajoutée, vous avez besoin d'une évaluation du risque que la bibliothèque ne se comporte pas exactement comme prévu. Le moyen le plus courant est (comme dans Stack Exchange) la réputation . Si la bibliothèque est connue pour avoir été largement testée et qu'elle est toujours maintenue, le risque de tomber dans un cas d'angle non testé est faible et vous pouvez espérer que si vous remarquez un problème, il sera corrigé. Si elle n'est maintenue qu'occasionnellement et qu'elle compte peu d'utilisateurs, vous (ou vos utilisateurs) risquez de tomber plus tard dans une telle situation et de ne pas avoir de meilleur moyen que de documenter que votre application ne peut tout simplement pas faire cela. >

   Si la réputation n'est pas bien établie, vous pouvez essayer de creuser un peu le code. S'il semble bien structuré, bien documenté et contient des tests, vous pouvez au moins être sûr que les règles des meilleures pratiques ont été respectées. En complément, des tests montreront sur quel cas d'utilisation la bibliothèque se concentre.

   Si la bibliothèque ressemble vraiment à une obscure et que vous voulez l'utiliser, vous aurez pour tester non seulement votre propre code, mais également vérifier que la bibliothèque se comporte comme prévu pour tous les cas d'utilisation que vous souhaitez que votre application accepte. Parce que vous ne pouvez pas lui faire confiance aveuglément. Mais si vous faites cela sérieusement, cela prendra du temps.

2. PHP contre les langues moins utilisées

   PHP est probablement le langage le plus utilisé par les programmeurs non professionnels. Cela signifie que si vous avez besoin de quelque chose, quelqu'un d'autre l'a déjà produit. Mais vous ne pouvez pas être sûr de la qualité. Java est beaucoup moins utilisé en dehors des produits de qualité professionnelle. Mais de nombreuses bibliothèques sont produites par de grandes organisations bien connues et fortement testées. Quand j'obtiens quelque chose des projets Spring, j'espère qu'il a suivi les règles des meilleures pratiques et qu'il a été largement testé.

   Seulement mon avis mais c'est l'une des raisons pour lesquelles je suis réticent à utiliser du code PHP: il y a Il y a beaucoup de code PHP, dont certains de très bonne qualité, mais le risque d'obtenir un morceau de code de mauvaise qualité est élevé.

Le conseil est essentiellement une cartographie des principes de confiance que l'on a dans le monde «réel» dans le monde du développement logiciel:

• Ne faites pas aveuglément confiance à quelqu'un mais vérifiez sa réputation. Il vaut mieux faire confiance à quelqu'un à qui beaucoup d'autres font déjà confiance depuis un certain temps, car dans ce cas, il est moins probable que la confiance soit abusée. Pour le développement de logiciels, cela signifie utiliser des bibliothèques qui sont également utilisées par d'autres et qui ont une bonne réputation.
• Et si vous avez affaire à quelqu'un qui n'a pas encore de réputation établie, soyez très prudent. En cas de développement logiciel, cela signifie vérifier que le code fait réellement ce qu'il est censé faire et rien de plus (c'est-à-dire pas de portes dérobées, pas de bogues critiques).

Si vous ne suivez pas ces règles simples du monde réel dans le développement logiciel, vous pouvez vous brûler de la même manière que vous pouvez être brûlé dans la vraie vie: quelqu'un pourrait abuser de la confiance (non fondée) que vous avez ce qui peut par exemple entraîner une porte dérobée ou un bug critique dans votre logiciel. Et cela pourrait aussi nuire à votre propre réputation.

Bien sûr, il est toujours possible que quelqu'un ait une bonne réputation et abuse encore de la confiance. Et il y a suffisamment d'exemples où cela est fait. Mais c'est beaucoup moins probable par rapport à quelqu'un sans réputation car il faut beaucoup d'efforts pour se bâtir une bonne réputation en premier lieu. Par rapport à cela, une bonne réputation peut être facilement et rapidement perdue si elle est mal utilisée, donc la plupart n'essaieront pas d'abuser de leur bonne réputation.

Vous n'avez pas besoin d'utiliser PHP pour votre site Web

Il existe de meilleures alternatives. Regardez dans ocsigen qui est conçu par des informaticiens comprenant quelque chose sur la cybersécurité et dans haxe. Bien sûr, vous passerez des mois à l'apprendre, et si vous choisissez d'utiliser ocsigen, vous prenez des risques commerciaux (les personnes et les entreprises qui le maintiennent pourraient disparaître, ce qu'on appelle facteur de bus). Mais je connais personnellement le principal architecte et concepteur d'Ocsigen, et je peux vous assurer qu'il comprend assez bien la cybersécurité (la moitié de sa thèse de doctorat porte sur ce sujet).

Je dois non plus utilisez-le ou rien.

Non, c'est faux. Vous n'êtes pas obligé d'utiliser PHP. Par exemple, lisez ce blog sur la création de votre site Web en C ++ et celui-là sur les technologies Web en Common Lisp. Vous pouvez utiliser d'autres approches (par exemple les serveurs FastCGI écrits en C ++ ou en Go, votre serveur HTTP spécialisé écrit en C ++, par exemple avec libonion ou avec pistache ou avec CppCMS ou Wt, dans Go, dans Common Lisp avec SBCL). Avec Rocket.rs, vous pouvez écrire des applications Web dans Rust (et la communauté Rust se soucie beaucoup de la cybersécurité). Vous pouvez programmer des serveurs Web dynamiques en SML. Et de nombreux serveurs Web ( Apache, Lighttpd, ...) peuvent être personnalisés ou adaptés à vos besoins (par exemple avec vos plugins écrits par vous pour eux) sans un seul élément lié à PHP.

Mon opinion biaisée est que les frameworks Web au-dessus de Common Lisp ou C ++ ou Go ou Rust sont généralement conçus par des informaticiens formés qui, par profession, comprennent et se soucient de la cybersécurité. PHP a été conçu avec un état d'esprit complètement différent: être capable de coder rapidement des sites Web dynamiques. Au moment de la conception de PHP (1995), la cybersécurité n'était pas une préoccupation majeure, mais être en mesure de créer un beau site Web dynamique en quelques jours était en pratique essentiel.

Mais quoi que vous utilisiez, cela a un certain coût. En savoir plus sur les externalités. Lisez les travaux universitaires de J.Tirole sur eux (il est un prix Nobel d'économie; son article sur l'économie simple de l'open source vaut la peine d'être lu, et le plus cité sur ce sujet). Même s'il s'agit de logiciel libre (puisque le logiciel libre est une question de liberté, pas de budget). N'oubliez pas au moins le coût de vos efforts pour l'apprendre et évaluer ses aspects de cybersécurité.

Si vous utilisez des bibliothèques open source, elles ont encore un certain coût pour vous: vous besoin de les apprendre, de les évaluer. Ils sont généralement donnés SANS GARANTIE . Mais vous pouvez acheter un support pour ces bibliothèques.

Si vous utilisez des bibliothèques propriétaires ou des composants logiciels, vous êtes lié par leur CLUF.

La sécurité est toujours un question de compromis.

Vous pouvez ne pas attacher votre ceinture de sécurité lorsque vous conduisez, mais alors vous prenez un risque supplémentaire et vous payez pour cela (par exemple parce que votre assurance ne vous couvrira pas si quelque chose se passe faux, ou parce que vous obtenez une amende). Il en est de même pour les choix de logiciels.

Attention cependant au théorème de Rice. À certains égards, cela indique qu'une cybersécurité totale est impossible. Mais même vivre est une activité risquée. (Vous ou moi pourriez avoir une crise cardiaque dans quelques heures).

Votre problème n'est pas technique, mais social. Si vous utilisez un logiciel open source, vous avez la possibilité d'étudier chaque ligne de code source et d'être convaincu (ou non) que la sécurité est suffisante. Bien sûr, cela pourrait prendre des décennies (ou des siècles: une distribution Linux entière représente maintenant 20 milliards de lignes de code source). Mais le choix vous appartient (et vous pouvez déléguer l'évaluation de la sécurité de chaque composant logiciel que vous utilisez).

Je pense que vous suivez déjà les conseils! Vous dites:

Je ne compte pas les obsolètes, abandonnés, poubelles.

Alors, quelle mesure utilisez-vous pour décider si quelque chose est "obsolète , abandonné, poubelle "? Très peu de paquets sont en fait marqués comme "abandonnés" sur des sites comme packagist.org, et "trash" est clairement un jugement subjectif, donc je soupçonne que votre processus actuel est quelque chose comme ceci:

1. Rechercher des packages d'apparence pertinente
2. Vérifiez s'ils correspondent à votre cas d'utilisation
3. Vérifiez qu'ils sont d'une qualité raisonnable

Le fait que vous finissez souvent avec une seule option à la fin de ce processus est très différent du fait qu’il n’y a qu’une seule option au début de ce processus.

C'est aussi il convient de noter que s'il existe une bibliothèque de haute qualité pour résoudre un travail particulier, il n'y a souvent aucune incitation pour quelqu'un à en écrire une nouvelle. Encore une fois, cela ne va pas à l'encontre du conseil d'utiliser des bibliothèques bien respectées, cela le renforce - s'il y a beaucoup de gens qui utilisent la même implémentation, il est plus probable que certains d'entre eux détectent des failles ou paient pour des audits. Ceci est fondamentalement une réitération de la "loi de Linus":

avec suffisamment de globes oculaires, tous les bugs sont superficiels

Le seul cas où je peux voir le problème en fait postuler, c'est là où il n'y a pas de bibliothèques décentes pour un travail, car c'est un cas d'utilisation suffisamment rare que personne n'en a écrit. Dans cette situation, c'est à vous d'écrire la bibliothèque (ou de payer pour qu'elle soit écrite), et à vous de la sécuriser (ou de payer quelqu'un pour la vérifier).