Sécurité PHP : Comment protéger un site contre les injections SQL et les XSS

Votre code PHP dans le viseur : pourquoi le silence n'est pas d'or

Imaginez : vous avez lancé un site, tout fonctionne comme sur des roulettes, les clients sont satisfaits. Pendant ce temps, dans un coin sombre d'Internet, un script-kiddie saisit dans votre formulaire de recherche la chaîne magique ' OR 1=1 --. Et la base de données, tel un serviteur obéissant, lui délivre tous les mots de passe des utilisateurs. Une histoire familière ? Malheureusement, pour de nombreux développeurs débutants, oui.

La sécurité en PHP n'est pas une bureaucratie ennuyeuse, mais une protection réelle de votre temps, de votre argent et de votre réputation. Aujourd'hui, nous allons décortiquer les deux principaux ennemis des applications web : les injections SQL et le cross-site scripting (XSS). Vous apprendrez à les reconnaître, les neutraliser et ne plus jamais les laisser entrer dans votre code.

Injections SQL : quand l'utilisateur devient hacker

Une injection SQL est une attaque où un attaquant « injecte » du code SQL malveillant via des champs de saisie. Si vous insérez simplement les données de l'utilisateur dans une requête, considérez que vous avez vous-même ouvert la porte au cambrioleur.

À quoi ressemble un code vulnérable

Voici un exemple classique que l'on trouve encore dans de vieux manuels et sur des sites en ligne :

<?php\n// DANGEREUX ! Ne faites jamais cela\n$username = $_POST['username'];\n$password = $_POST['password'];\n\n$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";\n$result = mysqli_query($conn, $query);\n?>

Que se passe-t-il si l'on saisit admin' -- dans le champ username ? La requête devient :

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

Le double tiret -- commente le reste de la requête. Et voilà : l'attaquant se connecte en tant qu'admin sans mot de passe. Et si l'on saisit '; DROP TABLE users; -- ? Adieu les utilisateurs.

La bouée de sauvetage : les requêtes préparées (Prepared Statements)

La meilleure façon de se protéger contre les injections SQL est d'utiliser des requêtes préparées avec PDO ou MySQLi. Elles séparent la logique de la requête des données, de sorte que le code malveillant ne s'exécute jamais.

Voici à quoi ressemble un code sécurisé avec PDO :

<?php\n// SÉCURISÉ ! Utilisons des requêtes préparées\n$username = $_POST['username'];\n$password = $_POST['password'];\n\n$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");\n$stmt->execute(['username' => $username, 'password' => $password]);\n$user = $stmt->fetch();\n?>

Maintenant, même si l'attaquant transmet admin' OR 1=1 --, PDO le traitera comme une simple chaîne de caractères, et non comme une partie d'une commande SQL. La base de données dira : « Je cherche un utilisateur avec ce nom étrange ». Et elle ne le trouvera pas.

Pourquoi PDO plutôt que mysql_* ?

\n
• Sécurité par défaut : PDO échappe automatiquement les données.
\n
• Flexibilité : prend en charge différents SGBD (MySQL, PostgreSQL, SQLite).
\n
• Placeholders nommés : le code devient lisible et maintenable.
\n
• Approche orientée objet : un style de programmation moderne.
\n

Les fonctions mysql_* ont été supprimées de PHP 7.0, et c'est tant mieux. Si vous utilisez encore mysqli_real_escape_string — c'est mieux que rien, mais PDO reste plus fiable.

Attaques XSS : quand le code se cache dans les commentaires

Le cross-site scripting (XSS) est l'injection de code JavaScript sur une page via une saisie utilisateur. Imaginez : un utilisateur laisse un commentaire, mais au lieu d'un texte, il écrit :

<script>alert('Votre site est piraté !');</script>

Si vous affichez cela sans traitement, chaque visiteur verra une fenêtre contextuelle. Et si au lieu de alert, il y a du code qui vole les cookies ou redirige vers un site de phishing ?

Types d'attaques XSS

\n
• Reflected (réfléchi) : le code malveillant