En bref : les extensions PHP sont des modules écrits en C qui ajoutent des fonctions à PHP, comme les pilotes de base de données (PDO), le chiffrement (Sodium, OpenSSL) ou le cache de bytecode OPcache. Le manuel PHP distingue les extensions Core, Bundled, External et PECL. Elles sont chargées via extension ou zend_extension dans le php.ini. Chaque extension s'exécute dans le processus PHP avec ses droits. D'où la règle : ne charger que ce qui est nécessaire, et la mettre à jour avec PHP.
Que sont les extensions PHP ?
Le noyau de PHP, la Zend Engine, peut exécuter du code, mais beaucoup de ce dont les applications ont besoin se trouve dans des extensions. Elles sont écrites en C et sont soit compilées directement dans PHP, soit chargées au démarrage comme bibliothèque partagée (.so sous Linux, .dll sous Windows).
Un point important pour les décideurs : les extensions ne sont pas des plugins de l'application, mais font partie de l'environnement d'exécution PHP. Elles sont installées par l'hébergeur ou l'administrateur du serveur, pas par l'agence dans le CMS. Si une extension manque, l'application signale le plus souvent une erreur lors de l'installation ou de la mise à jour.
La distinction avec les paquets Composer est tout aussi importante. Composer installe des bibliothèques écrites en PHP et situées dans le dossier du projet, par exemple un paquet de messagerie ou de PDF. Les extensions, en revanche, sont du code compilé chargé au démarrage de PHP et valable pour toutes les applications du serveur. De nombreux paquets Composer exigent certaines extensions et le notent dans leur composer.json avec des entrées comme ext-intl ou ext-sodium. Pour vérifier si un projet trouve toutes les extensions nécessaires, on peut exécuter composer check-platform-reqs dans le dossier du projet.
Quels types d'extensions existe-t-il ?
Le manuel PHP répartit les extensions en quatre groupes :
| Groupe | Signification selon le manuel | Exemples du manuel |
|---|---|---|
| Core | partie du noyau de PHP, non désactivable | Arrays, Date/Time, Hash, JSON, PCRE, SPL, Strings |
| Bundled | livrées avec PHP | BC Math, Ctype, Fileinfo, Filter, GD, intl, mbstring, PDO, Sessions |
| External | livrées avec PHP, nécessitent des bibliothèques externes | cURL, DOM, GMP, LDAP, OpenSSL, Sodium, Zip |
| PECL | disponibles via PECL, en partie avec des bibliothèques externes | APCu, Memcached, MongoDB, Yaml |
La répartition peut changer. Avec PHP 8.4, selon la page de publication, les extensions IMAP, OCI8, PDO_OCI et pspell ont été retirées de la distribution et déplacées vers PECL. Qui les utilise a besoin, après la mise à niveau, d'une installation séparée qui doit elle aussi être maintenue.
Comment les extensions sont-elles chargées ?
Selon le manuel, les extensions partagées sont chargées via la directive extension du php.ini ; les extensions Zend, qui interviennent plus profondément dans le moteur, via zend_extension. Les deux ne peuvent figurer que dans le php.ini. Le répertoire est défini par extension_dir, pour lequel le manuel recommande un chemin absolu.
; extensions ordinaires
extension=pdo_mysql
extension=sodium
extension=intl
; extension Zend : OPcache (à charger avant Xdebug si les deux sont actifs)
zend_extension=opcache
Des distributions comme Debian et Ubuntu placent pour chaque extension un petit fichier .ini distinct dans le répertoire d'analyse, par exemple sous /etc/php/8.3/mods-available/, et les activent par SAPI avec phpenmod et phpdismod. La manière dont PHP lit ces fichiers est expliquée dans Le php.ini expliqué.
Les extensions s'installent le plus souvent via la gestion de paquets, par exemple le paquet php8.3-intl. Les extensions PECL peuvent être compilées avec pecl ou phpize. Selon le manuel, PECL est déprécié ; on recommande le PHP Installer for Extensions (PIE). Qui compile PHP entièrement lui-même trouvera des indications sous Compiler PHP à partir du code source.
Vérifier les extensions : lesquelles sont réellement chargées ?
Les commandes suivantes sont en lecture seule. Notez que la ligne de commande peut charger d'autres extensions que le site web.
php -m # modules de la CLI
php-fpm8.3 -m # modules de PHP-FPM 8.3 (nom selon la distribution)
php --re sodium | head -n 5 # fonctions d'une extension
php --ri opcache # configuration d'une extension
php -r 'var_dump(extension_loaded("intl"));'
Dans le code, les applications vérifient avec extension_loaded() si une extension est présente, et avec get_loaded_extensions() lesquelles sont chargées :
<?php
$benoetigt = ['pdo_mysql', 'mbstring', 'intl', 'sodium'];
$fehlend = array_diff($benoetigt, array_map('strtolower', get_loaded_extensions()));
echo $fehlend ? 'Fehlt: ' . implode(', ', $fehlend) : 'Alle Erweiterungen vorhanden';
Extensions et sécurité : moins, c'est mieux
Les extensions s'exécutent dans le même processus que PHP et avec les mêmes droits. Une erreur dans une extension peut donc peser aussi lourd qu'une erreur dans le noyau. Quatre règles en découlent :
- Ne charger que ce qui est nécessaire. Chaque extension supplémentaire élargit la surface d'attaque. Comparez votre liste aux exigences système de l'application.
- Mettre à jour avec PHP. Les extensions fournies arrivent avec la mise à jour de PHP. Les extensions PECL et tierces nécessitent leurs propres mises à jour et doivent correspondre à la nouvelle version de PHP.
- Pas d'outils de développement en production. Les débogueurs et profileurs comme Xdebug n'ont leur place que dans les environnements de développement.
- Verrouiller des fonctions de façon ciblée. Lorsque des extensions apportent des fonctions pour les commandes système, Bien utiliser disable_functions aide.
Avec PHP2Shell, les failles se situent dans le noyau de PHP, non dans une extension. Désactiver des modules ne les comble pas ; il faut la mise à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, avec redémarrage de tous les processus PHP. Après la mise à jour, vérifiez que toutes les extensions sont de nouveau chargées, car des modules manquants ne se remarquent souvent que pour certaines fonctions. Comment garder durablement les dépendances sous contrôle est décrit dans Maintenir les dépendances à jour.
Comment PHP SOS aide-t-il concrètement ?
- Recenser le parc : nous listons, pour chaque SAPI, toutes les extensions chargées avec leur origine et leur version.
- Faire le tri : nous comparons la liste aux besoins de votre application et désactivons le superflu après test.
- Mettre à jour : dans le cadre du durcissement de serveur, nous amenons PHP et toutes les extensions tierces à un état maintenu.
- Vérifier après les mises à jour : nous contrôlons qu'après chaque mise à jour de PHP, tous les modules nécessaires sont de nouveau chargés.
Questions fréquentes
Quelle est la différence entre extension et zend_extension ?
Avec extension, PHP charge des extensions ordinaires comme les pilotes de base de données. Avec zend_extension, selon le manuel, sont chargées des extensions Zend qui interviennent plus profondément dans le moteur, par exemple OPcache ou Xdebug. Ces deux directives ne peuvent figurer que dans le php.ini.
Comment voir quelles extensions sont chargées ?
En ligne de commande avec php -m ; pour le site web, via la fonction get_loaded_extensions() dans un fichier de test déposé brièvement, ou via php-fpm -m de la version concernée. Notez que la CLI et la SAPI web peuvent charger des extensions différentes.
Qu'est-ce que PECL et qu'est-ce que PIE ?
PECL est un répertoire d'extensions PHP fournies via le système de paquets PEAR. Selon le manuel PHP, PECL est déprécié ; on recommande à la place le PHP Installer for Extensions (PIE).
Désactiver une extension corrige-t-il PHP2Shell ?
Non. Les failles PHP2Shell se situent dans le noyau de PHP, non dans une extension désactivable. Moins d'extensions réduisent la surface d'attaque en général, mais ne remplacent pas la mise à jour vers une version corrigée.