Attaques PHP : les failles les plus courantes et comment les contrôler

PHP fait tourner une grande partie du web : sites WordPress, boutiques WooCommerce, applications Laravel, back-offices sur mesure. C’est précisément pour cette raison qu’il est autant ciblé. Les robots d’attaque ne cherchent pas « votre » site : ils balaient Internet en continu à la recherche de failles connues, et frappent là où la porte est ouverte.

La bonne nouvelle, c’est que PHP n’est pas un langage dangereux en soi. Les failles viennent presque toujours de la manière dont le code est écrit, configuré et maintenu. Les comprendre, c’est déjà savoir les éviter.

Pourquoi les applications PHP sont attaquées

Trois raisons reviennent sans cesse :

• Le volume : plus une technologie est répandue, plus une seule faille peut être exploitée sur des milliers de sites.
• Le code ancien : beaucoup de projets ont été développés il y a des années, puis modifiés par plusieurs prestataires sans revue globale.
• Les mises à jour oubliées : version de PHP en fin de support, extensions WordPress abandonnées, dépendances Composer jamais actualisées.

Voici les attaques les plus fréquentes, ce qu’elles exploitent, et comment les bloquer.

1. L’injection SQL

Le principe : l’attaquant glisse du code SQL dans un champ (formulaire, URL, cookie) que l’application colle directement dans sa requête.

// VULNÉRABLE : la saisie devient du code SQL
$id = $_GET['id'];
$result = $pdo->query("SELECT * FROM commandes WHERE id = $id");

Avec id=1 OR 1=1, la requête renvoie toutes les commandes. Selon les droits de la base, l’attaquant peut lire des données clients, modifier des comptes, voire supprimer des tables.

La protection : les requêtes préparées. La donnée est envoyée séparément de la requête et ne peut jamais être interprétée comme du SQL.

// SÉCURISÉ - requête préparée : la saisie reste une simple valeur
$stmt = $pdo->prepare('SELECT * FROM commandes WHERE id = :id');
$stmt->execute(['id' => (int) $_GET['id']]);

À compléter par un utilisateur de base de données qui n’a que les droits nécessaires : un site vitrine n’a aucune raison de pouvoir supprimer une table.

2. Le XSS (cross-site scripting)

Le principe : l’attaquant enregistre du JavaScript dans un commentaire, un nom de profil ou un champ de recherche. Ce script s’exécute ensuite dans le navigateur des autres visiteurs, y compris des administrateurs : vol de session, faux formulaires, redirections.

// VULNÉRABLE : le contenu saisi est affiché tel quel
echo "<p>Bonjour " . $_GET['nom'] . "</p>";

La protection : échapper systématiquement à l’affichage, selon le contexte (HTML, attribut, JavaScript, URL).

// SÉCURISÉ : les caractères spéciaux deviennent du texte inoffensif
echo '<p>Bonjour ' . htmlspecialchars($_GET['nom'], ENT_QUOTES, 'UTF-8') . '</p>';

Les moteurs de templates comme Blade (Laravel) ou Twig échappent par défaut, et WordPress fournit esc_html(), esc_attr() et esc_url(). Un en-tête Content-Security-Policy ajoute une seconde barrière en limitant les scripts autorisés.

3. Le CSRF (falsification de requête)

Le principe : un administrateur connecté visite une page piégée qui envoie, à son insu, une requête vers votre back-office : changer un e-mail, supprimer un compte, valider une commande. Le serveur voit une session valide et exécute l’action.

La protection :

• un jeton CSRF unique dans chaque formulaire sensible, vérifié côté serveur (natif dans Laravel avec @csrf, et via les nonces dans WordPress) ;
• des cookies de session en SameSite=Lax ou Strict ;
• jamais d’action qui modifie des données via une simple requête GET.

4. L’upload de fichiers malveillants

Le principe : un formulaire accepte une « photo de profil » ou un « justificatif ». L’attaquant envoie en réalité un script PHP déguisé (facture.php.jpg, faux type MIME). Si le fichier est stocké dans un dossier public et que le serveur l’exécute, l’attaquant prend la main sur le site.

C’est l’une des failles les plus graves, car elle mène souvent à une prise de contrôle complète du serveur.

La protection :

• vérifier le type réel du fichier (avec finfo), pas seulement l’extension ou le type envoyé par le navigateur ;
• renommer le fichier avec un nom généré par l’application ;
• stocker les uploads hors du dossier public, ou dans un dossier où l’exécution de PHP est désactivée ;
• limiter la taille et la liste des formats acceptés.

5. L’inclusion de fichiers et l’exécution de code

Le principe : l’application choisit un fichier à inclure à partir d’un paramètre d’URL. En manipulant ce paramètre, l’attaquant fait lire des fichiers sensibles (../../.env) ou exécuter du code.

// VULNÉRABLE : le visiteur décide du fichier inclus
include $_GET['page'] . '.php';

La protection : ne jamais construire un chemin de fichier avec une donnée utilisateur. Utiliser une liste blanche (['accueil', 'contact', 'services']) et refuser tout le reste. Les fonctions comme eval(), unserialize() sur des données externes ou exec() doivent être évitées ou strictement encadrées.

6. Les comptes, mots de passe et sessions

Les attaques : essais automatisés de milliers de mots de passe (brute force), réutilisation de mots de passe volés ailleurs, vol ou fixation de session.

La protection :

• hacher les mots de passe avec password_hash() et les vérifier avec password_verify(), jamais en MD5 ou SHA1 ;
• limiter le nombre de tentatives de connexion et ajouter une double authentification sur les comptes administrateurs ;
• régénérer l’identifiant de session à la connexion (session_regenerate_id(true)) ;
• cookies de session en HttpOnly, Secure et SameSite ;
• vérifier les droits sur chaque action côté serveur, pas seulement masquer un bouton dans l’interface.

7. La configuration et les fichiers exposés

Beaucoup d’incidents ne viennent pas du code, mais de l’environnement :

• display_errors activé en production, qui affiche chemins, requêtes et parfois mots de passe ;
• fichiers .env, .git/, sauvegardes .sql ou .zip accessibles depuis le navigateur ;
• version de PHP en fin de support, qui ne reçoit plus de correctifs de sécurité ;
• dépendances Composer ou extensions WordPress avec des failles publiées ;
• pas de HTTPS, ou absence d’en-têtes de sécurité (Strict-Transport-Security, X-Content-Type-Options, Content-Security-Policy).

La protection : une configuration de production dédiée, des fichiers sensibles hors du dossier public, composer audit dans le cycle de livraison, et un plan de mise à jour régulier.

Comment DEV EVOLUER contrôle les failles

La sécurité n’est pas un module que l’on ajoute à la fin. Chez DEV EVOLUER, elle fait partie de la manière de concevoir, livrer et maintenir une application. Concrètement, notre méthode suit quatre étapes.

1. Auditer : savoir où l’on en est

Avant de corriger, il faut un état des lieux réel :

• revue du code sur les points sensibles : requêtes SQL, formulaires, uploads, authentification, droits, appels d’API ;
• analyse des dépendances : version de PHP, paquets Composer, thème et extensions WordPress ;
• contrôle de la configuration : erreurs affichées, fichiers exposés, HTTPS, en-têtes, permissions des dossiers.

Le résultat est une liste de failles classées par gravité, avec pour chacune le risque concret et la correction proposée.

2. Corriger : commencer par ce qui expose le plus

Les corrections sont priorisées : d’abord ce qui permet de prendre le contrôle du site ou d’accéder aux données (injection SQL, upload, accès administrateur), puis le reste. Chaque correction est versionnée avec Git, testée, puis déployée sans casser les fonctionnalités existantes. C’est le même travail que lorsque nous reprenons un projet WordPress existant.

3. Renforcer : réduire la surface d’attaque

Une fois les failles corrigées, nous durcissons l’ensemble : configuration PHP de production, en-têtes de sécurité, droits minimaux sur la base de données, suppression des extensions inutiles, sauvegardes automatiques et testées.

4. Surveiller et maintenir dans le temps

Une application sécurisée aujourd’hui peut devenir vulnérable demain, simplement parce qu’une faille est découverte dans une dépendance. Nous mettons en place des journaux d’erreurs et de connexions exploitables, des mises à jour planifiées et une vérification régulière des dépendances.

Aucun prestataire sérieux ne peut promettre un site « impossible à pirater ». L’objectif est de fermer les portes les plus utilisées par les attaquants, de détecter rapidement un comportement anormal et de pouvoir restaurer le site sans perte en cas d’incident.

Et pour les développeurs : apprendre les bons réflexes

La plupart des failles décrites ici s’évitent avec quelques réflexes appris tôt : requêtes préparées, échappement à l’affichage, validation côté serveur, gestion propre des sessions. C’est pourquoi la sécurité est intégrée dès les premiers exercices de la formation PHP de DEV EVOLUER Academy, et non reléguée à la fin du parcours.

Votre application PHP est-elle exposée ?

Si votre site ou votre application tourne sur PHP, WordPress ou Laravel, et que vous ne savez pas quand il a été vérifié pour la dernière fois, un audit permet d’y voir clair avant qu’un robot ne le fasse à votre place.

Parler de votre projet avec DEV EVOLUER

• #sécurité PHP
• #failles PHP
• #injection SQL PHP
• #faille XSS
• #protection CSRF
• #audit sécurité site web Tunisie
• #sécuriser site WordPress