En bref : une revue de code de sécurité pour PHP consiste à lire le code source de façon ciblée avec une question : où des saisies tierces peuvent-elles faire ce qu'elles ne devraient pas ? Deux formes ont fait leurs preuves : une revue de chaque modification et une revue de référence de l'ensemble du projet, appuyées sur l'analyse statique avec PHPStan ou Psalm. Une revue ne trouve pas les failles de l'interpréteur PHP comme PHP2Shell, mais bien les nombreuses erreurs qui naissent dans le code propre.
Pourquoi examiner précisément maintenant son propre code ?
PHP2Shell a surtout occupé les administrateurs durant la dernière semaine d'octobre 2026. Corriger, redémarrer, prouver : le travail se faisait sur le serveur. Pour les équipes de développement, une question inconfortable subsiste ensuite. Si un attaquant peut exécuter du code via une autre faille, que trouve-t-il dans notre application ? Et combien de ces failles avons-nous écrites nous-mêmes ?
L'OWASP Top 10 montre depuis des années que la plupart des vulnérabilités des applications web n'ont rien d'exotique. Le contrôle d'accès manquant, l'injection et la configuration non sécurisée figurent tout en haut. Ce sont des erreurs qu'un regard exercé trouve dans le code source, bien avant qu'un attaquant ne les essaie.
S'y ajoute une raison pratique. De nombreuses entreprises font de toute façon contrôler, corriger et durcir leurs serveurs en ce moment. Qui examine sa propre application dans la foulée comble l'écart entre l'exploitation et le développement. Un serveur durci avec une application vulnérable reste attaquable, tout comme une application proprement écrite sur un PHP non corrigé.
Revue de référence ou revue des modifications ?
L'aide-mémoire OWASP sur la revue de code sécurisée distingue deux types qui, en pratique, se complètent :
| Type | Quand | Étendue | Objectif |
|---|---|---|---|
| Revue de référence (baseline) | nouveau projet, grande release, après un incident | projet entier, pondéré selon le risque | recenser les vulnérabilités existantes |
| Revue des modifications (diff) | chaque pull request | uniquement le code modifié | empêcher de nouvelles erreurs |
Une revue de référence après un incident est particulièrement précieuse. Qui vient de nettoyer un serveur devrait savoir si l'application offre d'autres portes d'entrée. La revue des modifications maintient ensuite l'état propre, car chaque modification est lue aussi sous l'angle de la sécurité avant la fusion.
Revue de code en PHP : où se concentrent les erreurs de sécurité
Dans les projets PHP, un examen ciblé de certaines fonctions et de certains motifs vaut la peine. Ils ne sont pas interdits, mais chaque occurrence mérite la question de savoir si des données tierces peuvent y pénétrer.
| Motif dans le code | Risque possible | Pour approfondir |
|---|---|---|
| SQL par concaténation de chaînes avec des variables | injection SQL | Empêcher l'injection SQL en PHP |
unserialize() sur des données extérieures |
injection d'objets | Désérialisation non sécurisée en PHP |
include ou require avec un chemin variable |
inclusion de fichiers tiers | Empêcher les inclusions de fichiers locales et distantes |
exec(), system(), shell_exec(), proc_open() |
exécution de commandes | injection de commandes |
Sortie sans htmlspecialchars() |
cross-site scripting | échappement adapté au contexte |
== sur des jetons ou des hachages |
la conversion de types contourne les contrôles | hash_equals(), comparaisons strictes |
eval(), extract() sur des saisies |
injection de code ou de variables | le plus souvent à supprimer sans remplacement |
Une première vue d'ensemble rapide est possible avec une simple recherche. Elle ne remplace pas une revue, mais montre par où commencer :
# Occurrences de fonctions à risque dans le code propre (vendor exclu)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Ce qui manque dans le code est au moins aussi important. Chaque contrôleur vérifie-t-il que l'utilisateur connecté a le droit de voir ou de modifier précisément cet enregistrement ? Les téléversements sont-ils limités quant au type et à l'emplacement de stockage ? De telles failles, aucune recherche de noms de fonctions ne les trouve, seule la lecture du déroulement le fait.
Les outils qui soutiennent la revue
L'analyse statique examine le code sans l'exécuter. PHPStan et Psalm trouvent des erreurs de type, du code inaccessible et des hypothèses erronées sur les valeurs de retour. Psalm propose en plus une analyse de souillure (taint) qui suit si des données issues de requêtes parviennent sans contrôle à des endroits critiques. Les deux peuvent être renforcés par niveaux, de sorte que même des projets plus anciens peuvent s'y mettre. Un aperçu est donné dans Analyse statique : PHPStan et Psalm.
# Analyse statique du projet, augmenter le niveau progressivement
vendor/bin/phpstan analyse src --level=5
# Analyse de souillure avec Psalm
vendor/bin/psalm --taint-analysis
Les outils fournissent des indices, pas des verdicts. Chaque résultat appelle une évaluation, et un rapport vide ne signifie pas que l'application est sûre.
Aussi important que la découverte, la consignation. Chaque constat devrait être enregistré avec son emplacement, une brève description, une estimation du risque, la correction recommandée et le statut, de préférence directement dans le système de tickets de l'équipe. On peut ainsi retracer ce qui a été corrigé, ce qui a été accepté en connaissance de cause et ce qui reste ouvert. Après la correction, un second regard vaut la peine : la cause est-elle éliminée ou seulement un symptôme ? Le même motif apparaît-il à d'autres endroits du code ? Une erreur commise une fois ne se trouve, d'après l'expérience, que rarement à un seul endroit.
Une liste de contrôle pour votre équipe
Pour les revues de modifications, une liste courte et fixe a fait ses preuves. Elle a sa place dans le modèle de pull request :
- D'où viennent toutes les données que cette modification traite, et sont-elles contrôlées côté serveur ?
- Les requêtes de base de données sont-elles construites exclusivement avec des paramètres ?
- Chaque sortie est-elle échappée pour son contexte, c'est-à-dire HTML, attribut, JavaScript ou URL ?
- Le code vérifie-t-il l'autorisation pour précisément cet objet, et pas seulement la connexion ?
- Des mots de passe, des jetons ou des données personnelles aboutissent-ils dans des journaux ou des messages d'erreur ?
- Des secrets figurent-ils dans le code ou dans des fichiers versionnés ?
- De nouvelles dépendances ont-elles été ajoutées, et sont-elles maintenues ?
Faites toujours lire les parties critiques pour la sécurité, comme la connexion, la gestion des droits, les parcours de paiement et les téléversements, par une seconde personne qui n'a pas participé au code. Le regard extérieur trouve des hypothèses que l'auteur juge évidentes.
Comment PHP SOS aide-t-il concrètement ?
- Nous réalisons avec des partenaires spécialisés une revue de référence de votre application PHP, pondérée selon les parties au risque le plus élevé.
- Nous configurons PHPStan ou Psalm en fonction de l'état de votre projet et rédigeons la liste de contrôle pour vos pull requests.
- Nous associons la revue à un regard sur le serveur et la configuration, car de nombreuses failles naissent seulement de l'interaction.
- Lorsqu'un contrôle depuis l'extérieur est souhaité, nous complétons la revue par un audit de sécurité et test d'intrusion.
Conclusion : une revue de code est l'endroit le moins coûteux pour corriger les erreurs de sécurité, à savoir avant leur mise en production. Qui contrôle chaque modification avec une courte liste et passe de temps en temps le projet entier en revue réduit durablement la surface d'attaque.
Questions fréquentes
Quelle est la différence entre une revue de code et un test d'intrusion ?
Une revue de code lit le code source et trouve les erreurs avant leur mise en production. Un test d'intrusion attaque l'application en fonctionnement depuis l'extérieur. Les deux se complètent : la revue trouve les causes, le test montre ce qui est réellement exploitable.
Une revue de code trouve-t-elle des failles comme PHP2Shell ?
Non. PHP2Shell se trouve dans l'interpréteur PHP, pas dans le code de l'application. Seule une mise à jour de PHP avec redémarrage y remédie. Une revue trouve les erreurs du code propre, par exemple l'injection, les contrôles d'autorisation manquants ou la désérialisation non sécurisée.
PHPStan ou Psalm suffisent-ils pour une revue de sécurité ?
Ils constituent une bonne base et trouvent automatiquement de nombreuses erreurs. Les erreurs de logique, les contrôles d'autorisation manquants et les hypothèses erronées sur les processus ne sont toutefois repérés que par un humain qui sait ce que l'application doit faire.
Combien de temps dure une revue de code de sécurité ?
Cela dépend de l'étendue. Une revue de chaque modification dans la pull request coûte peu de temps. Une revue complète d'un projet qui s'est étoffé est un chantier à part, que l'on limite selon le risque aux parties les plus importantes.