Avec PDO les requêtes préparées, en plus du gain de rapidité d'exécution pour un script ayant
à faire plusieurs fois le même type de requêtes, ont l'intérêt de ne pas nécessiter de protection pour les paramétres entrées, le pilote de notre BDD s'en occupant lui même (cf PHP5 avancé 3e edition).

Ma question est la suivante : Est-il pertinent et économe d'un point de vue performance de ne les utiliser que pour ce dernier aspect et peut-on alors abandonner les verifications de formulaires ?

Même si les requêtes préparées de PDO te protègent des injections SQL, cela ne te dispense par pour autant de vérifier les données transmises par un formulaire (notamment s'il n'y pas de \n ou de \r présageant une tentative d'injection d'en-tête, s'il s'agit d'un formulaire de contact, par exemple).

Plus tu as de niveaux de vérification, mieux ce sera pour la sécurité de ton script.

Bref, pour la sécurité, il ne faut pas exclusivement se reposer sur certaines bibliothèques, certaines fonctions ou certains paramètres de configuration de PHP : si les requêtes préparées de PDO ou des fonctions comme mysql_real_escape_string() ou htmlspecialchars() sont d'une grande aide, certains paramètres de configuration comme magic_quotes (quand ils sont activés) apportent plus d'inconvénients que d'assurance en terme de sécurité (d'ailleurs, cette directive sera supprimée en PHP 6).

Effectivement, même si tu n'exécutes tes requêtes préparées qu'une fois, le gain de sécurité vaut largement toute perte de performance théorique.

En pratique, même s'il faut un petit peu plus de temps (CPU) pour préparer une requête, ça ne représente même pas 0.001s sur une page nécessitant 20 requêtes, donc l'aspect sécuritaire écrase l'aspect performance.

Tant qu'on est sur le sujet, il existe deux façons de préparer ses requêtes : localement par PDO, ou sur le serveur via le pilote MySQL. PDO permet d'utiliser l'un ou l'autre via l'option PDO::ATTR_EMULATE_PREPARES (PDO::MYSQL_ATTR_DIRECT_QUERY avant PHP 5.1.3). Les requêtes préparées localement sont un peu plus performantes.

PS: oh noes, grillé par Victor Brito
PPS: j'avais oublié d'aborder les formulaire. Comme l'ami Victor le disait, l'un n'empêche pas l'autre : filtre tes formulaires en entrée pour supprimer les données invalides (ou afficher une erreur à l'utilisateur), protège tes requêtes et filtre aussi ce que tu affiches en sortie. Même si tu utilises strip_tags() sur les données de ton formulaire, n'hésite pas à utiliser htmlspecialchars() lorsque tu les affiches sur ton site

Merci à vous deux, j'en profite pour poser une question supplémentaire,.
Sur le site que je développe (qui est mon premier "from scratch" ou presque) , j'hesite régulierement sur le fait de savoir si je dois vérifier ou non les formulaires lorsque ceci sont passés en $_POST et où l'utilisateur n'a aucun champ à remplir, comme par exemple une balise select etc...

En fait je suis hésitant sur le degres de paranoia qu'il faut avoir

Même si le formulaire utilise la méthode POST, il est toujours bon de vérifier si les données sont valables et correspondent à ce à quoi on s'attend ordinairement.

Bref, n'hésite pas à être paranoïaque.

Ecoute, ne soit pas paranoïaque, et je te ferais un programme en C qui te prouvera qu'il faut l'être en t'envoyant justement ce que tu ne veux pas recevoir.

La sécurité du côté serveur n'a absolument pas à se préoccuper de ce qui se passe du côté client. Tu as beau faire toutes les vérifications possibles et inimaginables sur chez le client, tu dois partir du principe que tu ne les as pas faites, et que le client à un contrôle total des données qu'il envoie, car c'est le cas. En effet, même si tu n'en as pas forcément conscience, le navigateur n'est qu'un logiciel comme un autre, et les données envoyées à priori par un navigateur pourraient tout aussi bien être envoyées par un programme destiné spécialement à t'attaquer, et dans lequel un utilisateur malveillant aurait entré toutes les données nécessaires pour faire tomber tes sécurités.

Bref, tu dois toujours partir dans l'optique que toutes les données que tu reçois (même les cookies ou certaines variables server) peuvent avoir été envoyées de n'importe quoi et peuvent être de n'importe quelle nature, il n'y a que si tu es sur que les données sont locales au serveur et déjà sécurisées que tu peux t'abstenir de vérification…