// On récupère le résultat
if ($requete->fetch())
{
echo 'Le client existe !';
}
} catch (Exception $e)
{
die('Erreur : ' . $e->getMessage());
}
Pourquoi nous avoir fait apprendre la syntaxe SQL si on ne s'en sert jamais ?
D'abord parce qu'il est toujours intéressant de savoir comment fonctionnent les requêtes préparées.
Ensuite, parce qu'il pourrait arriver qu'il n'existe aucune API ni extension permettant de faire des requêtes préparées pour le
langage dans lequel vous programmez, auquel cas, bien entendu, il faudrait construire vos requêtes préparées vous-mêmes.
Ou vous pourriez tomber sur l'un des rares cas où il vous serait nécessaire de préparer une requête directement en SQL.
Enfin, vous aurez peut-être besoin de faire quelques tests impliquant des requêtes préparées directement dans MySQL.
Cependant, si une API ou une extension existe et répond à vos besoins, utilisez-la ! Elle sera généralement plus performante et
plus sécurisée que ce que vous pourriez faire vous-mêmes.
Utilité
Les requêtes préparées sont principalement utilisées pour deux raisons :
protéger son application des injections SQL ;
gagner en performance dans le cas d'une requête exécutée plusieurs fois par la même session.
Empêcher les injections SQL
En général, quand on crée une application, l'utilisateur peut interagir avec celle-ci. L'utilisateur peut créer un membre sur un site
web communautaire, un personnage sur un jeu vidéo, etc. Les actions de l'utilisateur vont donc avoir une incidence sur la base
de données de l'application. Il va envoyer certaines informations, qui vont être traitées, puis une partie va être envoyée sous
forme de requêtes à la base de données.
Il existe un adage bien connu en programmation : "Never trust user input" traduit en français par "Ne jamais faire confiance aux
données fournies par l'utilisateur".
Lorsque l'on traite des données qui viennent de l'extérieur, il est absolument impératif de toujours vérifier celles-ci, et de protéger
les requêtes construites à partir de ces données. Ceci évite que l'utilisateur, volontairement ou non, fasse ce qu'on appelle une
injection SQL et provoque un comportement inattendu et souvent indésirable, voire dangereux, pour les données.
Les injections SQL sont un type de failles exploitables par l'utilisateur. Il existe de nombreux autres types de failles.
Passons maintenant à la question qui doit vous brûler les lèvres.
Mais qu'est-ce qu'une injection SQL ?
On appelle injection SQL le fait qu'un utilisateur fournisse des données contenant des mots-clés SQL ou des caractères
particuliers qui vont détourner ou modifier le comportement des requêtes construites sur la base de ces données.
Imaginons que vous créiez un site web avec un espace membre.
Vos membres ont accès à une page "profil" grâce à laquelle ils peuvent gérer leurs informations, ou supprimer leur compte. Pour
supprimer leur compte, ils ont simplement à appuyer sur un bouton qui envoie leur numéro d'id.
D'un côté on a donc une requête incomplète :
Code : SQL
Partie 5 : Sécuriser et automatiser ses actions
262/414
www.openclassrooms.com
if ($requete->fetch())
{
echo 'Le client existe !';
}
} catch (Exception $e)
{
die('Erreur : ' . $e->getMessage());
}
Pourquoi nous avoir fait apprendre la syntaxe SQL si on ne s'en sert jamais ?
D'abord parce qu'il est toujours intéressant de savoir comment fonctionnent les requêtes préparées.
Ensuite, parce qu'il pourrait arriver qu'il n'existe aucune API ni extension permettant de faire des requêtes préparées pour le
langage dans lequel vous programmez, auquel cas, bien entendu, il faudrait construire vos requêtes préparées vous-mêmes.
Ou vous pourriez tomber sur l'un des rares cas où il vous serait nécessaire de préparer une requête directement en SQL.
Enfin, vous aurez peut-être besoin de faire quelques tests impliquant des requêtes préparées directement dans MySQL.
Cependant, si une API ou une extension existe et répond à vos besoins, utilisez-la ! Elle sera généralement plus performante et
plus sécurisée que ce que vous pourriez faire vous-mêmes.
Utilité
Les requêtes préparées sont principalement utilisées pour deux raisons :
protéger son application des injections SQL ;
gagner en performance dans le cas d'une requête exécutée plusieurs fois par la même session.
Empêcher les injections SQL
En général, quand on crée une application, l'utilisateur peut interagir avec celle-ci. L'utilisateur peut créer un membre sur un site
web communautaire, un personnage sur un jeu vidéo, etc. Les actions de l'utilisateur vont donc avoir une incidence sur la base
de données de l'application. Il va envoyer certaines informations, qui vont être traitées, puis une partie va être envoyée sous
forme de requêtes à la base de données.
Il existe un adage bien connu en programmation : "Never trust user input" traduit en français par "Ne jamais faire confiance aux
données fournies par l'utilisateur".
Lorsque l'on traite des données qui viennent de l'extérieur, il est absolument impératif de toujours vérifier celles-ci, et de protéger
les requêtes construites à partir de ces données. Ceci évite que l'utilisateur, volontairement ou non, fasse ce qu'on appelle une
injection SQL et provoque un comportement inattendu et souvent indésirable, voire dangereux, pour les données.
Les injections SQL sont un type de failles exploitables par l'utilisateur. Il existe de nombreux autres types de failles.
Passons maintenant à la question qui doit vous brûler les lèvres.
Mais qu'est-ce qu'une injection SQL ?
On appelle injection SQL le fait qu'un utilisateur fournisse des données contenant des mots-clés SQL ou des caractères
particuliers qui vont détourner ou modifier le comportement des requêtes construites sur la base de ces données.
Imaginons que vous créiez un site web avec un espace membre.
Vos membres ont accès à une page "profil" grâce à laquelle ils peuvent gérer leurs informations, ou supprimer leur compte. Pour
supprimer leur compte, ils ont simplement à appuyer sur un bouton qui envoie leur numéro d'id.
D'un côté on a donc une requête incomplète :
Code : SQL
Partie 5 : Sécuriser et automatiser ses actions
262/414
www.openclassrooms.com