filter_input contre $_GET direct : sécuriser la lecture d’un paramètre d’URL

Undefined array key "page" : ce message, familier à quiconque a activé l’affichage des avertissements PHP sur un environnement de développement, apparaît dès qu’un code lit $_GET['page'] sans vérifier au préalable que cette clé existe réellement dans l’URL appelée.

Sur un serveur de production avec les erreurs masquées, ce genre d’avertissement passe souvent inaperçu à l’écran, mais il continue de s’accumuler dans les journaux, et surtout, le code qui suit s’exécute avec une valeur null implicite qui n’a parfois pas été anticipée dans la logique métier.

La lecture directe et ses angles morts

Le réflexe le plus répandu consiste à protéger la lecture avec isset() :

$page = isset( $_GET['page'] ) ? (int) $_GET['page'] : 1;

Cette approche fonctionne, mais elle multiplie les lignes dès qu’un paramètre nécessite un traitement plus riche : filtrage d’un entier dans une plage donnée, validation d’une adresse email, extraction d’un tableau de valeurs. Chaque cas demande alors sa propre logique ad hoc, dispersée dans le code au fil des besoins.

filter_input() : une alternative native de PHP

filter_input() est une fonction native de PHP, indépendante de WordPress, qui lit directement une superglobale tout en appliquant un filtre de validation ou de nettoyage. Sa signature accepte un type de superglobale, le nom de la variable, et un filtre optionnel :

$page = filter_input( INPUT_GET, 'page', FILTER_VALIDATE_INT );

if ( null === $page || false === $page ) {
    $page = 1;
}

Si la clé page est absente de l’URL, filter_input() renvoie null, sans lever le moindre avertissement. Si la clé existe mais ne correspond pas au filtre demandé — une chaîne de caractères là où un entier est attendu, par exemple — la fonction renvoie false, ce qui permet de distinguer les deux cas dans le code appelant.

Les filtres les plus utiles au quotidien

• FILTER_VALIDATE_INT pour un identifiant numérique, une pagination, un nombre d’éléments par page.
• FILTER_VALIDATE_EMAIL pour vérifier qu’une adresse email transmise en paramètre respecte un format valide.
• FILTER_VALIDATE_URL pour s’assurer qu’une URL de redirection transmise en paramètre est syntaxiquement correcte.
• FILTER_SANITIZE_FULL_SPECIAL_CHARS pour retirer les caractères spéciaux d’une chaîne avant tout affichage.

Chaque filtre applique sa propre logique de validation ou de nettoyage, ce qui évite d’écrire une fonction de vérification maison pour des cas déjà couverts nativement par PHP.

Un exemple avec plusieurs paramètres

$parametres = filter_input_array( INPUT_GET, array(
    'page'     => array(
        'filter'  => FILTER_VALIDATE_INT,
        'options' => array( 'default' => 1, 'min_range' => 1 ),
    ),
    'recherche' => FILTER_SANITIZE_FULL_SPECIAL_CHARS,
) );

$page      = $parametres['page'];
$recherche = $parametres['recherche'];

filter_input_array() traite plusieurs paramètres en une seule fois, avec la possibilité de définir une valeur par défaut et des bornes directement dans les options du filtre, sans code conditionnel supplémentaire.

Une limite à connaître

Un comportement surprend régulièrement les développeurs qui découvrent cette fonction : sous certaines configurations de serveur PHP en mode CLI ou avec certains SAPI, filter_input() peut ne pas refléter une modification de $_GET effectuée manuellement en cours de script, car la fonction lit une copie interne des superglobales capturée au démarrage de la requête, pas le tableau $_GET tel qu’il existe à l’instant de l’appel. Ce détail n’a généralement aucun impact en usage web classique, mais il vaut d’être gardé en tête sur des scripts exécutés en ligne de commande qui manipulent ces tableaux à la main.

Sur un projet où plusieurs développeurs interviennent, adopter systématiquement filter_input() pour les paramètres d’URL simplifie la relecture de code : le filtre appliqué documente à lui seul le format attendu.

En résumé

Cette fonction ne remplace pas une validation métier plus poussée — vérifier qu’un identifiant correspond réellement à un contenu existant reste une étape distincte — mais elle évite déjà l’essentiel des avertissements PHP liés à une lecture directe de superglobale, tout en centralisant le format attendu dans un seul appel plutôt que dans une succession de conditions.