Ne soyez pas pressé de faire défiler mon article - il ne s'agit pas du code, du seuil d'entrée, des frameworks ou du manque de compatibilité descendante.
Je me rapporte à PHP du côté qui se préoccupe de son hébergement et de sa sécurité. Bien sûr, maintenant, il ne sera pas difficile de fourrer le code avec l'interpréteur dans le conteneur, mais voici la sécurité ...
Regardez - chaque fois que vous accédez à votre code via l'interface Web, vous lancez un interpréteur qui lit tous les fichiers et génère une réponse. Y compris le fichier où vous avez si soigneusement spécifié l'accès à votre base de données. Et ne vous précipitez pas pour le chiffrer - après tout, vous devez également emporter la clé de déchiffrement quelque part, n'est-ce pas?
Je viens juste de voir comment, en utilisant l'une des vulnérabilités des anciennes versions, un hacker maléfique casse votre application dans l'ancien PHP5. Après tout, personne ne le prend plus en charge et le manque de compatibilité descendante vous empêche de passer à la nouvelle version.
Et donc le pirate informatique maléfique extrait le fichier avec l'accès à la base de données, lit et sourit joyeusement, lance une demande d'exécution, qui sort votre dame de la base de données et la donne docilement au méchant pour qu'elle soit déchirée.
Et peu importe si vous avez un blog régulier ou un site de cartes de visite là-bas. Et si une boutique en ligne? Et si une demande financière?
Ne dites pas qu'il n'y a pas de PHP dans la fintech. Il y a. J'ai personnellement vu.