Fonctions PHP désactivées par l'hébergeur : comprendre le blocage et s'en passer

Des fonctions interdites dans PHP existent parce que l'hébergement les retire par sécurité : la directive disable_functions du fichier php.ini désactive une fonction PHP comme exec, et le script PHP qui l'appelle s'arrête sur « Call to undefined function ».

Comment l'hébergeur désactive une fonction PHP

La directive disable_functions reçoit une liste de noms de fonctions internes, séparés par des virgules, et l'administrateur du serveur web la pose dans le fichier php.ini principal. Le manuel PHP la classe parmi les réglages modifiables seulement « dans php.ini » : ni ini_set() dans un script, ni un fichier .htaccess, ni un .user.ini placé dans le dossier du site ne peuvent la modifier.

; php.ini (côté serveur)
disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Sur un serveur sous PHP-FPM, l'administrateur peut aussi poser la directive dans la configuration du pool qui sert un site donné : deux sites hébergés sur la même machine n'ont donc pas forcément la même liste. La directive ne touche que les fonctions du langage et de ses extensions, jamais celles écrites par le développeur dans son propre code PHP.

Trois niveaux de réglage dans php.ini

Le tableau des directives de php.net indique pour chaque réglage où il peut changer. Les valeurs PHP_INI_ALL (memory_limit, par exemple) se modifient partout, y compris dans un script ; les valeurs PHP_INI_PERDIR (upload_max_filesize, post_max_size) se règlent par dossier, dans un .htaccess ou un .user.ini ; les valeurs PHP_INI_SYSTEM, dont disable_functions, restent réservées à l'administrateur. Cette hiérarchie explique qu'un client puisse relever sa limite mémoire mais jamais rendre une fonction interdite. Une erreur de mémoire, elle, se corrige donc souvent sans l'hébergeur, alors qu'un blocage de disable_functions passe toujours par lui.

Quelles fonctions sont le plus souvent interdites ?

Les fonctions interdites dans PHP sur un hébergement mutualisé sont d'abord celles qui exécutent un programme du système. Aucune liste officielle ne fixe le contenu de disable_functions : chaque hébergeur compose la sienne, et la seule source fiable reste la configuration de son propre compte. Les familles qui reviennent d'une liste à l'autre :

• Exécution de commandes : exec, system, shell_exec, passthru, popen, proc_open, pcntl_exec. Une seule suffit à lancer n'importe quel programme installé sur la machine.
• Gestion des processus et de l'environnement : proc_nice, posix_kill, putenv, dl (chargement d'une extension à la volée).
• Accès au système de fichiers hors du site : symlink, link, chown, chgrp, qui permettraient de pointer vers les fichiers d'un autre client.
• Divulgation de la configuration : phpinfo, show_source, highlight_file, parfois ini_get_all.
• Envoi de courrier : mail() est parfois coupée, pour limiter le spam depuis un site compromis.

Cette liste de fonctions interdites ne dit rien de ce qu'un hébergeur précis applique ; elle aide seulement à reconnaître la famille d'un blocage quand un message d'erreur apparaît.

Lire la configuration réelle de son hébergement

La liste active des fonctions désactivées se lit avec ini_get('disable_functions') dans un petit fichier PHP déposé à la racine du site. Le script ci-dessous l'affiche avec trois autres réglages utiles, dans une balise pre pour garder la mise en page :

<?php
echo '<pre>';
print_r(explode(',', ini_get('disable_functions')));
var_dump(function_exists('exec'));
var_dump(ini_get('open_basedir'));
var_dump(ini_get('memory_limit'));
echo '</pre>';

Le couple « print pre » rend la sortie lisible dans le navigateur sans code HTML supplémentaire. La page produite par phpinfo() affiche les mêmes valeurs, mais elle ne doit jamais rester en ligne : elle détaille la version, les chemins et les extensions du serveur à n'importe quel visiteur. Un fichier de test se supprime aussitôt après usage, et son nom ne se devine pas (évitez test.php ou info.php, que les robots essaient en premier).

Le panneau d'administration de certains hébergeurs affiche aussi la version de PHP et ses directives modifiables. Il ne montre pas toujours disable_functions : le script reste la vérification la plus sûre.

« Call to undefined function » : fonction interdite, supprimée ou absente ?

Le message « Call to undefined function » a trois causes possibles, et une fonction interdite n'en représente qu'une. Depuis PHP 8.0, les notes de migration indiquent qu'une fonction désactivée se comporte exactement comme une fonction inexistante : le moteur lève une erreur fatale au lieu de l'avertissement des versions 7, et un ancien script qui comptait sur l'avertissement s'arrête net après une migration vers PHP 7 ou 8 mal testée. Les deux autres causes produisent le même texte d'erreur :

Le cas des anciennes applications PHP et MySQL reste le plus fréquent : un site écrit avec mysql_connect() et mysql_query() pour lire une table MySQL ne tourne plus depuis PHP 7.0, sans qu'aucun réglage de l'hébergeur soit en cause. Le tableau des versions de php.net indique par ailleurs qu'en octobre 2026 seules les branches 8.2, 8.3, 8.4 et 8.5 reçoivent encore des correctifs, la 8.2 jusqu'au 31 décembre 2026.

Pourquoi interdire des fonctions sur un serveur web partagé

Un serveur web mutualisé héberge parfois des centaines de sites sous le même système, et une faille dans un seul CMS ne doit pas permettre de lancer des programmes, d'ouvrir une connexion vers l'extérieur ou de lire les fichiers des voisins. Retirer les fonctions d'exécution réduit ce qu'un intrus peut faire après avoir déposé un script PHP malveillant, souvent par un formulaire qui laisse passer des injections de code ou un envoi de fichier mal filtré.

Ces protections ont une histoire. L'ancien safe mode de PHP limitait les droits des scripts ; il a disparu en PHP 5.4, tout comme register_globals, qui transformait les paramètres GET et POST en variables globales et ouvrait la porte à des écrasements de variables. La directive open_basedir, souvent posée en même temps que disable_functions, limite les dossiers que PHP peut ouvrir ; le manuel la décrit comme un filet de sécurité supplémentaire et non comme une protection suffisante à elle seule. D'autres réglages complètent l'ensemble : cgi.force_redirect, à laisser actif quand PHP tourne en CGI derrière Apache, et allow_url_include, désactivée par défaut et dépréciée depuis PHP 7.4, qui empêche d'inclure un code PHP distant.

Le blocage vaut aussi pour l'hébergeur lui-même : un site compromis qui envoie du spam ou attaque d'autres serveurs met en cause l'adresse IP commune, et donc la délivrabilité des courriels de tous les clients de la machine.

Fonction interdite par l'hébergeur : réactivation, mail() et redéfinition

Peut-on réactiver une fonction PHP interdite par son propre php.ini ?

Non, sur un hébergement mutualisé la liste disable_functions fixée par l'administrateur l'emporte sur tout fichier php.ini ou .user.ini placé dans le dossier du site. Seul l'hébergeur peut la lever, sur demande au support ou en proposant une offre où le client règle lui-même PHP.

mail() fait-elle partie des fonctions interdites ?

Parfois, pour limiter les envois de spam depuis un site compromis. L'envoi passe alors par un serveur SMTP authentifié avec une bibliothèque comme PHPMailer, ce qui améliore aussi la délivrabilité vers les grandes messageries.

Peut-on créer une fonction qui porte le nom d'une fonction désactivée ?

Oui, depuis PHP 8.0 : une fonction désactivée étant traitée comme inexistante, le développeur peut déclarer une fonction de même nom dans son code. Cette possibilité sert à fournir un remplaçant inoffensif, mais elle ne rend pas l'accès au système que la directive retire.

Remplacer une fonction interdite sans changer d'hébergement

Une fonction interdite dans PHP a presque toujours un équivalent écrit en PHP pur ou fourni par une extension autorisée. Les remplacements les plus utiles :

• Lancer une tâche répétitive (exec d'un script en arrière-plan) : utiliser les tâches planifiées de l'hébergement, détaillées dans la réponse sur la crontab Linux et ses tables cron, qui appellent un script PHP à heure fixe.
• Redimensionner des images (appel à convert ou ImageMagick en ligne de commande) : les extensions GD ou Imagick, si elles sont activées.
• Télécharger un fichier distant (wget ou curl en ligne de commande) : l'extension cURL, ou file_get_contents avec allow_url_fopen, selon ce que l'hébergement autorise.
• Compresser une archive : les classes ZipArchive ou PharData plutôt qu'un appel à zip ou tar.
• Lister des fichiers (ls via shell_exec) : scandir, glob ou les itérateurs RecursiveDirectoryIterator.
• Besoin réel de commandes système : un serveur privé virtuel, où le client règle lui-même php.ini.

Avant de remplacer un appel, tester la présence de la fonction avec function_exists() permet d'écrire un code qui choisit la meilleure voie disponible, par exemple cURL si l'extension répond, file_get_contents sinon. Un message d'erreur clair vaut mieux qu'un écran blanc quand aucune voie n'existe.

Désactiver des fonctions sur son propre serveur

Sur un serveur privé, désactiver des fonctions dans PHP revient à éditer la ligne disable_functions du php.ini utilisé par le serveur web (et non celui de la ligne de commande, souvent distinct), puis à redémarrer PHP-FPM ou Apache. La commande php --ini indique quel fichier php.ini est chargé ; un script appelé par le navigateur peut afficher php_ini_loaded_file() pour la version servie aux visiteurs.

Les bonnes pratiques pour protéger un site sur sa propre machine :

• garder une copie du fichier d'origine avant toute modification ;
• partir d'une liste courte (exec, system, shell_exec, passthru, proc_open, popen) et l'allonger seulement si aucune application n'en a besoin ;
• vérifier les journaux d'erreurs après la modification : un CMS ou une extension qui appelle une fonction retirée s'y signale aussitôt ;
• combiner la directive avec open_basedir et un utilisateur système distinct par site ;
• ne jamais nommer un fichier de configuration config.inc.php sans que le serveur l'interprète : un fichier inc.php servi comme texte brut afficherait les identifiants de base de données. Le placer hors de la racine web, appelé depuis index.php, règle la question.

La directive disable_classes, son pendant pour les classes, reste moins utilisée : les classes dangereuses le sont surtout à travers les fonctions qu'elles appellent.

Fonction anonyme, fonctions personnalisées, mots interdits : les autres sens de la recherche

La recherche « fonctions interdites » mène aussi vers des questions de développement qui n'ont rien à voir avec la configuration du serveur. Trois d'entre elles reviennent souvent.

Créer des fonctions personnalisées en PHP

Une fonction personnalisée se déclare avec le mot-clé function, un nom, des paramètres et un bloc de code ; le manuel les appelle fonctions définies par l'utilisateur. La directive disable_functions ne les concerne jamais : elle vise uniquement les fonctions internes du langage. Un développeur qui veut créer des fonctions réutilisables les range souvent dans un fichier PHP inclus par require_once en tête de chaque page.

Fonction anonyme et classe anonyme

Une fonction anonyme, ou closure, est une fonction sans nom que l'on stocke dans une variable ou que l'on passe en argument ; elle est disponible depuis PHP 5.3, et la forme courte fn() => depuis PHP 7.4. Elle sert surtout de fonction de rappel : array_map, array_filter ou usort, chaque fonction array de ce type reçoit une closure qui décrit le traitement à appliquer. La classe anonyme, son équivalent objet introduit en PHP 7.0, crée un objet ponctuel sans déclarer de classe nommée. La closure remplace aussi create_function, retirée en PHP 8.0.

Interdire des mots dans un formulaire PHP

Interdire des mots dans un formulaire consiste à comparer les données POST reçues à une liste noire avant de les enregistrer : preg_match avec l'option i pour ignorer la casse, ou str_ireplace pour masquer le terme. Cette validation côté serveur se double toujours d'un échappement à l'affichage avec htmlspecialchars, sans quoi un visiteur glisserait du code HTML ou JavaScript dans la page. Une liste noire ne remplace pas une modération : les variantes orthographiques la contournent facilement.

Les autres questions sur les versions de PHP, la mémoire et les modules sont rassemblées dans la rubrique PHP et serveurs.

Sources : manuel PHP sur les directives du noyau du fichier php.ini (disable_functions, open_basedir, modes de modification), notes de migration de PHP 8.0, tableau des versions maintenues sur php.net consulté en octobre 2026.