Application web PHP & MySQL : les bases que j'applique à chaque projet

PDO plutôt que mysqli

Sur mes premiers essais, j'utilisais mysqli. Depuis, je suis passé sur PDO avec des requêtes préparées, plus lisible et plus simple à sécuriser contre les injections SQL :

// Jamais ça (injection SQL possible)
$sql = "SELECT * FROM utilisateur WHERE email = '" . $email . "'";

// Toujours ça (requête préparée)
$stmt = $pdo->prepare("SELECT * FROM utilisateur WHERE email = ?");
$stmt->execute([$email]);

Avec les paramètres liés (? ou :nom), la valeur n'est jamais interprétée comme du SQL. Simple, mais ça change tout.

Les mots de passe : jamais en clair, jamais

Sur RoutyGo et le forum, chaque compte utilisateur a son mot de passe haché avant d'être stocké — jamais en clair dans la base :

// À l'inscription
$hash = password_hash($motDePasse, PASSWORD_DEFAULT);

// À la connexion
if (password_verify($motDePasseSaisi, $hashEnBase)) {
    // connexion autorisée
}

Sur mon stage de deuxième année chez First Car, on est allés un cran plus loin côté Java avec JBCrypt pour l'appli desktop — même logique, juste une autre lib.

Ne jamais faire confiance à ce qui vient du formulaire

Toute donnée envoyée par un utilisateur doit être vérifiée côté serveur, même si elle est déjà validée côté JavaScript (qui peut toujours être contourné). Sur mes projets, je passe systématiquement les entrées dans une fonction de validation avant de les utiliser :

function valider_email($email) {
    return filter_var($email, FILTER_VALIDATE_EMAIL);
}

Et côté affichage, j'échappe toujours ce qui vient de la base avant de l'afficher (htmlspecialchars), pour éviter qu'un utilisateur malin injecte du HTML ou du JavaScript dans un commentaire, par exemple.

Les sessions et les tokens CSRF

Pour l'authentification, j'utilise les sessions PHP classiques ($_SESSION). Sur le projet de réservation de mon deuxième stage, on a ajouté des tokens CSRF sur les formulaires sensibles pour éviter qu'un site tiers puisse soumettre une action à la place de l'utilisateur sans qu'il le sache. Ça reste un réflexe simple à prendre dès qu'un formulaire modifie des données (pas juste un formulaire de recherche).

Ce que je retiens

• Requêtes préparées, toujours — même pour "juste un petit projet perso"
• Mots de passe hachés (password_hash/password_verify), jamais stockés en clair
• Valider et échapper toute donnée qui vient de l'utilisateur, côté serveur
• Penser aux tokens CSRF dès qu'un formulaire modifie des données

Rien de révolutionnaire, mais ce sont exactement les réflexes qui manquent le plus souvent dans les premiers projets — les miens y compris, au début.