Top erreurs des développeurs PHP débutants : niveau avancé

Top erreurs des développeurs PHP débutants : niveau avancé

Lorsque vous passez de scripts simples à des applications web complexes en PHP, le nombre d'embûches augmente considérablement. De nombreux développeurs, après avoir maîtrisé la syntaxe de base, commettent des erreurs systématiques qui entraînent des fuites mémoire, des vulnérabilités et une baisse des performances. Dans cet article, nous analyserons 4 erreurs avancées fréquemment rencontrées chez les développeurs de niveau intermédiaire et montrerons comment les corriger.

1. Mauvaise gestion des sessions et fuites mémoire

L'une des erreurs les plus insidieuses est la mauvaise gestion des sessions. De nombreux développeurs stockent de grandes quantités de données dans les sessions (par exemple, des résultats de requêtes de base de données ou des objets sérialisés). Cela ralentit non seulement le travail, mais peut également entraîner des fuites mémoire sur le serveur.

Problème : La session est verrouillée pendant l'exécution du script. Si vous y stockez 10 Mo de données, chaque requête lira et écrira ce volume, et en cas de requêtes parallèles, elles se mettront en file d'attente.

Exemple de mauvais code :

<?phpsession_start();// Charger dans la session un tableau de 10000 enregistrements$_SESSION['big_data'] = $db->query("SELECT * FROM logs")->fetchAll();?>

Solution : Utilisez les sessions uniquement pour l'identification (user_id, token). Stockez toutes les autres données dans le cache (Redis, Memcached) ou dans la base de données.

<?phpsession_start();$_SESSION['user_id'] = $user->id;// Les données sont récupérées à la demande$cache = new RedisCache();$data = $cache->get('user_data_' . $user->id);if (!$data) {    $data = $db->query("SELECT * FROM logs WHERE user_id = ?", [$user->id])->fetchAll();    $cache->set('user_data_' . $user->id, $data, 3600);}?>

2. Mauvais caching et ignorance de l'invalidation

La deuxième erreur la plus courante est le caching "pour toujours". Les développeurs définissent une durée de vie du cache (TTL) de 24 heures ou plus, puis s'étonnent que les utilisateurs voient des données obsolètes. Pire encore : le caching sans tenir compte des modifications dans la base de données.

Problème : Si vous mettez en cache une liste de produits pendant 1 heure et qu'un administrateur modifie le prix, les utilisateurs verront l'ancien prix pendant encore 60 minutes.

Exemple de mauvais code :

<?php$cacheKey = 'product_list';$products = $cache->get($cacheKey);if (!$products) {    $products = $db->query("SELECT * FROM products")->fetchAll();    $cache->set($cacheKey, $products, 86400); // 24 heures}?>

Solution : Utilisez le marquage du cache ou l'invalidation forcée lors de la modification des données.

<?php// Lors de la mise à jour d'un produitfunction updateProduct($id, $data) {    $db->update("products", $data, ["id" => $id]);    // Invalider le cache    $cache->delete('product_list');    $cache->delete('product_' . $id);}

// Lors de la lecture$products = $cache->remember('product_list', 3600, function() use ($db) {    return $db->query("SELECT * FROM products WHERE active = 1")->fetchAll();});?>

3. Injections SQL via des fonctions "sécurisées"

De nombreux développeurs pensent qu'en utilisant mysqli_real_escape_string() ou addslashes(), ils sont protégés contre les injections SQL. C'est une idée fausse dangereuse. Ces fonctions ne protègent pas contre tous les types d'attaques, en particulier lors de l'utilisation de LIKE, ORDER BY et LIMIT.

Problème : La fonction mysqli_real_escape_string() n'échappe pas les caractères pour l'opérateur LIKE (par exemple, % et _). Si vous insérez une entrée utilisateur dans LIKE, un attaquant peut accéder à des données qu'il ne devrait pas voir.

Exemple de vulnérabilité :

<?php$search = $_GET['q'];$safe = mysqli_real_escape_string($conn, $search);$query = "SEL