Pourquoi vous ne devez plus accéder directement aux variables superglobals en php?

Un jour, j'ai été reçu en entretien par un acteur majeur de la communauté open-source, celui-ci m'a posé une question particulière qui est restée gravée dans ma mémoire...

"Quelle est la principale alternative d'accès aux variables superglobales en php?".
Et là, blanc total, suivi d'un humble "je ne sais pas", après quoi il ajoute "si vous ne savez pas, ce n'est pas grave, peu de gens savent que l'accès direct aux superglobales tend à être déprécié depuis php 5.3.".

Et hop, plus tard sur google, quasiment rien sur la dépréciation des superglobales, mais, une info resurgit, et là je saisis mieux pourquoi il ne faut plus accéder directement aux variables superglobales.
Je vous fais donc partager mon expérience.

Pourquoi vous ne devez plus accéder directement aux variables superglobals en php?

Pour ceux qui ne savent pas ou plus (on ne sait jamais), ce qu'est une variable superglobal, voici un excellent tuto ici: http://php.net/manual/fr/language.variables.superglobals.php

L'un des points faibles de php se pose sur la sécurisation des variables transmises par un utilisateur, c'est aussi un passage obligé pour tout développeur à chaque conception d'application, et, parfois un casse-tête qui nous coûte un temps précieux.
Il existe même une pléthore de classes partagées, utilisant des filtres d'échappement de caractères spéciaux et j'en passe.

Le seul problème est que, chaque développeur a sa propre méthode de sécurisation des superglobales, quand par exemple PDO dispose d'une méthode unique de sécurisation des variables, totalement transparente du point de vue utilisateur.

Depuis php 5.2, a été introduit une fonction native qui fait le travail pour nous (pas totalement, mais presque), filter_input.
Oui, depuis php 5.2 me direz-vous, çà date, mais tout le monde ne le sait pas forcément, et j'en faisais parti.

Cette fonction permet de:

1. Valider (FILTER_VALIDATE), s'assurer que la donnée transmise correspond aux critères spécifiés.
2. Sécuriser (FILTER_SANITIZE), supprimer les caractères non désirés, appliquer des contraintes spécifiques. retourner l'intégrité des variables superglobales.

Par exemple, pour récupérer une variable post transmise par un formulaire, on écrira ceci:

<?php $my_string = filter_input(INPUT_POST, ‘my_string’, FILTER_SANITIZE_STRING); ?>

On pourra aussi choisir de ne pas protéger la variable en écrivant ceci:

<?php $my_string = filter_input(FILTER_POST, ‘my_string’, FILTER_UNSAFE_RAW); ?>

Ca paraît plus complexe de prime abord, mais les avantages à utiliser cette fonction sont très nombreux:

1. Rapidité d'exécution, php sécurise et valide pour vous.
2. Uniformisation des méthodes.
3. Refactoring simplifié sur des projets à fort turnover.
4. Centralisation des processus de sécurisation, validation/non validation.
5. Validation multi-critères et personnalisée avec fonctions de callback.

... 

Pour plus d'infos, rendez-vous sur la doc http://fr.php.net/filter_input

Maintenant que vous connaissez les nombreux avantages de filter_input, rendez cette méthode obligatoire tant que possible, c'est une question de logique et de bonne pratique :).

Edouard kombo.