En bref : un framework PHP est une ossature de code réutilisable qui résout déjà les tâches typiques d'une application web : acheminer les requêtes vers le bon code, traiter les données de formulaires, interroger les bases de données, produire les sorties. Parmi les frameworks PHP connus figurent Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP et Slim. Un framework apporte des briques de sécurité, mais ne protège pas des failles de l'interpréteur PHP comme PHP2Shell.
Qu'est-ce qu'un framework PHP ?
Sans framework, chaque équipe réécrit le routage, la validation des formulaires, les sessions et la gestion des erreurs. Un framework impose pour cela des briques et des conventions fixes. Cela fait gagner du temps, rend le code lisible pour les nouveaux développeurs et regroupe les fonctions de sécurité en un seul endroit, au lieu de les répartir sur des centaines de fichiers.
Pour la direction, une conséquence est surtout importante : en choisissant un framework, vous vous liez pour des années à son cycle de publication. Si le framework ne prend plus en charge une version de PHP ou n'est lui-même plus maintenu, chaque mise à jour devient plus coûteuse.
La plupart des frameworks modernes s'installent via Composer et respectent les normes du PHP-FIG, par exemple PSR-4 pour l'autoloading ou PSR-7 pour les messages HTTP.
Les frameworks PHP connus en comparaison
L'aperçu suivant s'appuie sur les auto-descriptions des projets sur leurs pages d'accueil. Nous omettons volontairement les classements par popularité ou part de marché, faute de source commune fiable.
| Framework | Auto-description (en substance) | Usage typique |
|---|---|---|
| Laravel | framework « piles incluses » pour applications web | développements sur mesure, portails, SaaS |
| Symfony | framework performant avec des composants réutilisables | applications grandes et durables ; composants dans d'autres projets |
| Laminas | poursuite du Zend Framework maintenue par la communauté | applications d'entreprise, middleware |
| CodeIgniter | petit framework aux fonctions puissantes | petites applications, faible barrière d'entrée |
| Yii | framework pour le développement rapide d'applications modernes | applications web, base de certains CMS |
| CakePHP | framework aux conventions MVC claires | applications classiques de bases de données |
| Slim | micro-framework pour applications web et API | API légères, services middleware |
Sur sa page d'accueil, Symfony cite Drupal, Laravel, API Platform et Composer comme projets utilisant des composants Symfony. Un framework se trouve donc souvent aussi là où on ne le voit pas directement. La page CMS et systèmes de boutique sur PHP montre ce qu'il en est pour les CMS et les boutiques.
Les briques communes à presque tous les frameworks
Malgré des philosophies différentes, la plupart des frameworks partagent une même structure. Toutes les requêtes passent par un unique point d'entrée, le front controller, le plus souvent public/index.php. Le serveur web lui transmet pour cela toute adresse pour laquelle il n'existe pas de vrai fichier.
# Exemple : Nginx redirige les chemins inconnus vers le front controller
root /var/www/app/public;
location / {
try_files $uri /index.php$is_args$args;
}
Avec Apache, c'est généralement une règle de réécriture dans le dossier public qui assure cette tâche, avec d'autres serveurs web une règle comparable. Dans tous les cas, il importe que le serveur web pointe vers le dossier public et non vers le répertoire principal du projet. Un répertoire de documents mal défini compte parmi les causes les plus fréquentes de fichiers de configuration soudainement accessibles publiquement.
L'avantage pour la sécurité : seul le dossier public se trouve dans la racine web. Configuration, code source et vendor sont un niveau au-dessus et ne sont pas accessibles par URL. Ensuite, le routeur attribue la requête à un contrôleur, un middleware vérifie l'authentification ou le jeton CSRF, et un moteur de modèles produit la sortie avec échappement automatique.
Comment choisir un framework ?
Pour un nouveau développement ou la reprise d'un projet existant, ces questions aident :
- Maintenance et cycle de publication : pendant combien de temps les versions reçoivent-elles des mises à jour de sécurité, et existe-t-il des versions à support prolongé ?
- Prise en charge de PHP : la version du framework utilisée fonctionne-t-elle sur une version de PHP qui reçoit elle-même des mises à jour de sécurité ? Cela figure dans les exigences du projet.
- Équipe et prestataires : l'équipe connaît-elle le framework, et trouvez-vous des spécialistes en cas d'urgence ?
- Écosystème : existe-t-il des paquets maintenus pour vos besoins, ou faudrait-il beaucoup développer soi-même ?
- Normes : si le framework respecte les interfaces PSR, les briques sont plus faciles à remplacer plus tard.
Pour les projets Laravel et Symfony, nous avons des pages dédiées à la sécurisation : Sécuriser les applications Laravel et Sécuriser les applications Symfony.
Ce qu'un framework apporte à la sécurité, et ce qu'il n'apporte pas
Les frameworks épargnent aux développeurs de nombreuses sources d'erreurs : requêtes préparées contre l'injection SQL, échappement automatique contre le cross-site scripting, protection CSRF pour les formulaires, hachages de mots de passe sûrs. Mais cela ne fonctionne que si l'équipe utilise ces briques et ne les contourne pas.
Contre PHP2Shell, tout cela n'aide pas. CVE-2026-109618 et CVE-2026-109619 se trouvent dans l'interpréteur PHP. L'équipe PHP évalue le risque comme le plus élevé avec mod_php ; un exploit y a été démontré avant même que le code de l'application ne s'exécute. Le framework n'entre donc pas en jeu. Seule la mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 et le redémarrage de tous les processus PHP y remédient.
Une mise à jour de framework et une mise à jour de PHP sont deux tâches distinctes. Toutes deux relèvent de la maintenance, mais seule la mise à jour de PHP comble PHP2Shell.
Pour les projets plus anciens s'ajoute un autre risque : si une application dépend d'une ancienne version de framework, elle dépend souvent aussi d'une ancienne version de PHP. Pour PHP 8.1 et les versions antérieures, le projet PHP ne fournit plus de mises à jour officielles.
Comment PHP SOS aide-t-il concrètement ?
- Nous déterminons le framework, la version et les exigences PHP de votre application et vérifions si les deux reçoivent encore des mises à jour de sécurité.
- Nous vérifions la structure : seul
publicse trouve-t-il dans la racine web, la configuration etvendorsont-ils protégés ? - Nous planifions séparément les mises à jour du framework et de PHP, les testons et les installons avec redémarrage de tous les workers.
- Pour les développements sur mesure, nous proposons un audit de sécurité et test d'intrusion qui vérifie de façon ciblée l'utilisation des fonctions de protection du framework.
Questions fréquentes
Quel est le meilleur framework PHP ?
Cela dépend du projet. Sont déterminants la taille et la durée de vie de l'application, le savoir-faire de l'équipe, la maintenance assurée par le projet et la prise en charge des versions actuelles de PHP. Un framework bien maintenu et connu de l'équipe est le plus souvent un meilleur choix que le plus en vogue du moment.
Un framework protège-t-il de PHP2Shell ?
Non. PHP2Shell se situe dans l'interpréteur PHP, et selon l'équipe PHP, un exploit a été démontré avec mod_php avant même que le code de l'application ne s'exécute. Aucune mise à jour de framework ne remplace la mise à jour de l'environnement d'exécution PHP et le redémarrage de tous les workers.
Qu'est-ce qu'un micro-framework ?
Un micro-framework ne fournit que le noyau, typiquement le routage, les middlewares et les objets requête-réponse. L'accès aux bases de données, les modèles ou les formulaires se choisissent soi-même. Slim, par exemple, se désigne lui-même comme un micro-framework pour PHP.
Que signifie le fait qu'un CMS utilise des composants Symfony ?
Il emploie certaines briques de Symfony, par exemple pour le traitement HTTP ou la console, sans reprendre tout le framework. Les avis de sécurité sur ces composants concernent alors aussi le CMS, ce qui compte pour la planification des mises à jour.