SAPI expliquée : comment PHP dialogue avec le serveur web

En bref : SAPI signifie Server Application Programming Interface, l'interface par laquelle PHP dialogue avec son environnement. Les SAPI typiques sont fpm-fcgi (PHP-FPM), apache2handler (mod_php), cgi-fcgi (php-cgi), litespeed et cli pour la ligne de commande. La SAPI détermine comment les requêtes arrivent, quel php.ini s'applique et quels processus doivent redémarrer après une mise à jour. Avec PHP2Shell, l'évaluation du risque en dépend même.

Qu'est-ce qu'une SAPI ?

PHP est lui-même un programme qui exécute du code. Pour pouvoir livrer des pages web, il a besoin d'une liaison avec un serveur web, avec la ligne de commande ou avec une autre application. Cette liaison est la SAPI. Elle reçoit les données de la requête, les transmet à la Zend Engine et renvoie la sortie.

On peut se représenter la SAPI comme une prise : le moteur reste le même, mais selon la prise, il s'adapte à Apache, à Nginx via FastCGI, à LiteSpeed ou au terminal. Chaque variante a ses forces, ses voies de configuration et ses pièges.

La SAPI décide surtout de trois choses qui comptent au quotidien :

1. Modèle de processus : PHP s'exécute-t-il dans le serveur web, comme service autonome avec des workers permanents ou comme processus éphémère à chaque appel ?
2. Configuration : quel php.ini est lu, et où des réglages supplémentaires peuvent-ils figurer, par exemple dans .htaccess, dans un .user.ini ou dans le pool FPM ?
3. Droits et séparation : sous quel utilisateur le code s'exécute-t-il, et peut-on séparer plusieurs sites les uns des autres ?

Dans les panneaux d'hébergement, les SAPI apparaissent sous d'autres noms. Plesk parle par exemple de gestionnaires PHP comme « FPM application », « FastCGI application » ou « Apache module ». Il s'agit des mêmes modes d'exécution que ceux décrits sur cette page. En cas de doute, le fichier de test ci-dessous, qui affiche le nom réel de la SAPI, aide à trancher.

Quelles SAPI PHP existe-t-il ?

Pour php_sapi_name(), le manuel PHP cite notamment ces valeurs de retour : apache, apache2handler, cgi (jusqu'à PHP 5.3), cgi-fcgi, cli, cli-server, embed, fpm-fcgi, litespeed et phpdbg. La liste n'est expressément pas exhaustive.

FrankenPHP est un serveur d'applications moderne qui intègre PHP directement. Il est lui aussi concerné par PHP2Shell et possède ses propres voies de mise à jour ; détails sous Sécuriser FrankenPHP.

Comment vérifier la SAPI de votre serveur

La SAPI d'un site web ne s'obtient que via le serveur web, pas en ligne de commande. Un petit fichier de test suffit :

<?php
// sapi-check.php : à supprimer aussitôt après l'appel
header('Content-Type: text/plain');
echo PHP_SAPI, "\n", PHP_VERSION, "\n", php_ini_loaded_file(), "\n";

En ligne de commande, on peut relever en lecture seule les variantes et services installés :

php -r 'echo PHP_SAPI, PHP_EOL;'          # toujours "cli"
ls /usr/sbin/php-fpm* 2>/dev/null           # versions de FPM installées
systemctl list-units --type=service | grep -i -E "php|lsws|apache2|httpd"
apachectl -M 2>/dev/null | grep -i php     # mod_php chargé ?

Pourquoi chaque SAPI peut avoir son propre php.ini

Selon le manuel PHP, PHP cherche d'abord un fichier php-SAPI.ini, donc par exemple php-cli.ini, et seulement ensuite php.ini. Des distributions comme Debian et Ubuntu vont plus loin et créent des dossiers distincts par SAPI, par exemple /etc/php/8.3/fpm/ et /etc/php/8.3/cli/.

Le moment diffère aussi : pour les modules serveur, PHP ne lit la configuration, selon le manuel, qu'une seule fois au démarrage du serveur web ; pour CGI et CLI, à chaque appel. Qui modifie un réglage doit donc savoir quelle SAPI est concernée. Plus de détails sous Le php.ini expliqué.

SAPI et sécurité : ce que PHP2Shell a montré

Selon les avis, PHP2Shell concerne PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP évalue le risque comme le plus élevé avec mod_php, parce qu'un exploit y a été démontré avant l'exécution du code de l'application. Les raisons figurent sous Pourquoi mod_php porte le risque le plus élevé.

Pour l'exploitation, la SAPI signifie avant tout une chose : elle détermine ce qui doit redémarrer après la mise à jour.

1. PHP-FPM : tous les pools et workers de chaque version installée
2. mod_php : le service Apache complet, pas seulement un rechargement
3. php-cgi et configurations FastCGI : tous les processus PHP restants
4. LiteSpeed : les processus PHP du serveur web, selon les instructions de l'éditeur
5. CLI : pas de processus permanents, mais mettre aussi à jour le paquet pour que les vérifications soient justes

À moyen terme, il vaut la peine d'abandonner mod_php. Le manuel PHP recommande PHP-FPM avec mod_proxy_fcgi pour les nouvelles installations Apache. Les bases sont décrites dans PHP-FPM expliqué.

Comment PHP SOS aide-t-il concrètement ?

• Recenser les SAPI : nous déterminons pour chaque serveur quels modes d'exécution et quelles versions de PHP sont réellement actifs.
• Redémarrer correctement : via le service de correctifs PHP, nous mettons à jour chaque SAPI et prouvons le redémarrage de tous les processus.
• Associer la configuration : nous montrons quel php.ini et quels réglages de pool s'appliquent à votre site web.
• Planifier la transition : là où mod_php ou php-cgi tourne, nous planifions et testons le passage à PHP-FPM.

Questions fréquentes

Sources

• Manuel PHP : php_sapi_name()
• Manuel PHP : fichier de configuration
• Manuel PHP : Apache 2 sous Unix
• php.net : avis de sécurité