Sécurité PHP : les 10 failles à éviter absolument en 2026

PHP alimente encore 77 % des sites avec un back-end server-side. C’est aussi la raison pour laquelle les failles PHP restent parmi les plus exploitées sur le web. Voici les vulnérabilités que tout développeur PHP doit connaître et éviter.

Faille 1 : Injection SQL

La reine des failles web depuis 20 ans. Elle survient quand une entrée utilisateur est directement concaténée dans une requête SQL :

// VULNÉRABLE
$id = $_GET['id'];
$query = "SELECT * FROM users WHERE id = $id";
// URL: /user?id=1 OR 1=1 → expose tous les utilisateurs

// SÉCURISÉ : requête préparée avec PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $id]);
$user = $stmt->fetch();

Utilisez toujours les requêtes préparées (PDO, MySQLi avec prepare). Jamais de concaténation de variables dans du SQL.

Faille 2 : XSS (Cross-Site Scripting)

Le XSS permet à un attaquant d’injecter du JavaScript dans vos pages, visible par d’autres utilisateurs :

// VULNÉRABLE
echo "Bonjour " . $_GET['name']; // ?name=<script>document.cookie</script>

// SÉCURISÉ
echo "Bonjour " . htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');

Encodez systématiquement toutes les données affichées provenant d’une source externe. Pour le HTML riche (éditeurs WYSIWYG), utilisez HTMLPurifier pour filtrer les balises autorisées.

Faille 3 : CSRF (Cross-Site Request Forgery)

Un site malveillant peut déclencher des actions sur votre application au nom d’un utilisateur connecté. Protection : les tokens CSRF, un jeton unique par session inclus dans chaque formulaire :

// Génération du token
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// Vérification à la soumission
if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'] ?? '')) {
    die('CSRF token invalide');
}

Symfony, Laravel et WordPress gèrent les tokens CSRF nativement.

Faille 4 : Upload de fichiers non sécurisé

Permettre l’upload sans vérification laisse les attaquants uploader des webshells PHP :

// VULNÉRABLE
move_uploaded_file($_FILES['file']['tmp_name'], 'uploads/' . $_FILES['file']['name']);

// SÉCURISÉ
$allowed_types = ['image/jpeg', 'image/png', 'image/webp'];
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file($_FILES['file']['tmp_name']);
if (!in_array($mime, $allowed_types, true)) {
    die('Type de fichier non autorisé');
}
$extension = match($mime) {
    'image/jpeg' => '.jpg',
    'image/png'  => '.png',
    'image/webp' => '.webp',
};
$filename = bin2hex(random_bytes(16)) . $extension;
move_uploaded_file($_FILES['file']['tmp_name'], 'uploads/' . $filename);

N’utilisez jamais le nom de fichier original. Générez un nom aléatoire. Vérifiez le MIME type réel (pas l’extension). Stockez les uploads hors de la racine web si possible.

Faille 5 : Inclusion de fichiers (LFI/RFI)

L’inclusion dynamique de fichiers basée sur des inputs utilisateur est catastrophique :

// VULNÉRABLE
include($_GET['page'] . '.php'); // ?page=../../etc/passwd%00

// SÉCURISÉ : whitelist explicite
$allowed = ['home', 'about', 'contact'];
$page = $_GET['page'] ?? 'home';
if (!in_array($page, $allowed, true)) $page = 'home';
include(__DIR__ . '/pages/' . $page . '.php');

Faille 6 : Exposition de données sensibles dans les erreurs

En production, les erreurs PHP ne doivent jamais s’afficher à l’écran — elles révèlent la structure de votre code, vos chemins de fichiers, et parfois des credentials. Dans php.ini ou .htaccess de prod : display_errors = Off, log_errors = On. Loguez les erreurs dans un fichier accessible uniquement en SSH.

Faille 7 : Mots de passe mal hashés

Utiliser MD5 ou SHA1 pour les mots de passe est une faute professionnelle en 2026 :

// VULNÉRABLE
$hash = md5($password); // crackable en secondes avec une rainbow table

// SÉCURISÉ
$hash = password_hash($password, PASSWORD_ARGON2ID); // ou PASSWORD_BCRYPT
if (password_verify($input, $hash)) { /* connexion OK */ }

Faille 8 : Session hijacking

Régénérez l’ID de session après chaque changement de privilège (connexion, déconnexion) : session_regenerate_id(true). Configurez les cookies de session avec HttpOnly, Secure et SameSite=Strict.

Faille 9 : Désérialisation non sécurisée

La fonction unserialize() sur des données non fiables peut permettre l’exécution de code arbitraire. Utilisez JSON (json_decode()) pour les échanges de données. Si vous devez utiliser unserialize, passez un tableau d’options allowed_classes pour limiter les classes instanciables.

Faille 10 : Dépendances Composer non auditées

Vos dépendances Composer sont du code tiers qui tourne dans votre application. Lancez composer audit (disponible depuis Composer 2.4) pour scanner vos dépendances contre la base CVE de sécurité. Intégrez cette vérification dans votre CI/CD pour bloquer les déploiements avec des vulnérabilités connues.

Besoin d’un expert ? Développeur PHP sécurisé — Paris →

Questions fréquentes

Quelles sont les failles PHP les plus fréquentes en 2026 ?

Les vulnerabilités OWASP les plus fréquentes en PHP : injections SQL (PDO avec requêtes préparées est la solution), XSS (htmlspecialchars() sur toute sortie utilisateur), CSRF (tokens de formulaire), upload de fichiers non sécurisé (validation du type MIME côté serveur, jamais côté client), et exposition de données sensibles dans les messages d’erreur en production.

Comment sécuriser une API REST PHP ?

Authentification par JWT ou OAuth 2.0, validation stricte de tous les inputs (type, longueur, format), rate limiting pour éviter les abus, HTTPS obligatoire, en-têtes de sécurité HTTP (CORS strict, Content-Security-Policy), et journalisation des accès pour détecter les comportements anormaux. N’exposez jamais les messages d’erreur PHP détaillés en production.