Développement PHP : prévenir les principales failles de sécurité

PHP reste l’un des langages les plus utilisés pour développer des applications web dynamiques. Sa sécurité ne dépend toutefois pas uniquement du langage lui-même. Elle repose aussi sur la version utilisée, la qualité du code, la configuration du serveur, les bibliothèques intégrées et les pratiques de développement.

Une application PHP peut être exposée à des injections, des attaques XSS, des vols de session, des erreurs de configuration ou encore des failles dans ses dépendances. Il est donc essentiel d’intégrer la sécurité dès la conception.

Utiliser une version de PHP encore supportée

La première règle consiste à utiliser une version de PHP qui bénéficie toujours de mises à jour de sécurité.

PHP applique désormais un cycle de support de quatre ans par branche : deux années de support actif, puis deux années supplémentaires consacrées aux correctifs de sécurité critiques. PHP

En octobre 2026, les branches supportées sont notamment :

• PHP 8.2 : support sécurité jusqu’au 31 décembre 2026 ;
• PHP 8.3 : jusqu’au 31 décembre 2027 ;
• PHP 8.4 : jusqu’au 31 décembre 2028 ;
• PHP 8.5 : jusqu’au 31 décembre 2029.

Il faut également installer régulièrement les versions correctives publiées par l’équipe PHP. Des mises à jour de sécurité ont encore été publiées en 2026 pour plusieurs branches. PHP

Une version PHP arrivée en fin de vie ne doit donc pas rester en production sans dispositif spécifique de maintenance étendue.

Se protéger contre les injections SQL

Les injections restent parmi les vulnérabilités les plus connues des applications web.

Le risque apparaît lorsqu’une application construit une requête SQL en concaténant directement des données fournies par l’utilisateur.

La bonne pratique consiste à utiliser des requêtes préparées avec paramètres liés. OWASP les considère comme la défense principale contre les injections SQL. OWASP Cheat Sheet Series

Avec PDO, on privilégiera par exemple :

$stmt = $pdo->prepare(
    'SELECT id, email FROM users WHERE email = :email'
);

$stmt->execute([
    'email' => $email
]);

À éviter :

$sql = "SELECT * FROM users WHERE email = '$email'";

Dans le second exemple, une donnée utilisateur peut modifier la requête SQL si elle n’est pas correctement protégée.

La validation des entrées reste également importante. Elle complète les requêtes préparées, mais ne les remplace pas.

Prévenir les attaques XSS

Une attaque XSS permet d’injecter du contenu exécutable dans une page web. Elle peut notamment servir à voler des données, détourner une session ou modifier l’affichage d’une page.

La protection repose principalement sur l’encodage des données au moment de leur affichage.

En PHP, pour du contenu affiché dans du HTML, on peut utiliser :

echo htmlspecialchars(
    $nom,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

Cependant, la protection doit toujours être adaptée au contexte d’affichage : HTML, attribut, URL ou JavaScript.

OWASP insiste également sur l’intérêt des frameworks modernes et des moteurs de templates qui proposent un échappement automatique. OWASP Cheat Sheet Series

Une Content Security Policy (CSP) peut compléter cette protection. Elle limite notamment les sources de scripts autorisées et réduit l’impact de certaines attaques XSS. Elle constitue toutefois une défense complémentaire, et non un remplacement de l’encodage des sorties. OWASP Cheat Sheet Series

Protéger les formulaires contre le CSRF

Les attaques CSRF exploitent la session déjà ouverte d’un utilisateur pour déclencher une action à son insu.

Cela peut concerner, par exemple :

• une modification de mot de passe ;
• une suppression de compte ;
• une modification d’adresse ;
• une action d’administration.

Pour limiter ce risque, les formulaires sensibles doivent utiliser un jeton CSRF généré côté serveur et vérifié lors de la soumission.

Les cookies de session peuvent également bénéficier de l’attribut SameSite, qui réduit certains scénarios d’attaque. OWASP Cheat Sheet Series

Sécuriser les sessions et les cookies

Une application PHP manipule souvent des sessions pour identifier les utilisateurs.

Il convient notamment de :

• activer session.use_strict_mode ;
• utiliser des cookies Secure sur HTTPS ;
• activer HttpOnly ;
• utiliser un attribut SameSite adapté ;
• renouveler l’identifiant de session après une authentification ;
• limiter la durée de vie des sessions ;
• invalider correctement la session lors de la déconnexion.

La configuration PHP et celle du serveur jouent donc un rôle essentiel dans la sécurité de l’application. OWASP recommande notamment de vérifier les réglages du fichier php.ini et de maintenir une branche PHP officiellement supportée. OWASP Cheat Sheet Series

Gérer correctement les mots de passe

Une application ne doit jamais stocker les mots de passe en clair.

PHP fournit directement des fonctions adaptées :

$hash = password_hash(
    $password,
    PASSWORD_DEFAULT
);

Puis, lors de l’authentification :

if (password_verify($password, $hash)) {
    // Authentification réussie
}

Il faut éviter de développer soi-même un mécanisme de hachage ou d’utiliser des algorithmes généralistes anciens comme MD5 ou SHA-1 pour stocker des mots de passe.

Maîtriser les dépendances et la chaîne logicielle

Les applications PHP modernes reposent souvent sur Composer et de nombreuses bibliothèques externes.

Or l’OWASP Top 10 2025 intègre désormais explicitement les défaillances de la chaîne d’approvisionnement logicielle parmi les risques majeurs. OWASP Top 10

Il faut donc :

• maintenir les dépendances à jour ;
• supprimer les bibliothèques inutilisées ;
• surveiller les vulnérabilités connues ;
• conserver le fichier composer.lock ;
• éviter les packages abandonnés ;
• analyser régulièrement les dépendances.

La sécurité du code développé en interne ne suffit plus. Une faille dans une bibliothèque externe peut compromettre toute l’application.

Configurer correctement PHP et le serveur web

Une application peut être correctement développée mais rester vulnérable à cause d’une mauvaise configuration.

En production, il faut notamment éviter d’afficher les erreurs détaillées aux utilisateurs.

Par exemple :

display_errors = Off
log_errors = On

Les erreurs doivent être enregistrées côté serveur, sans exposer les chemins internes, les requêtes SQL ou des informations techniques sensibles dans les pages publiques.

Il est également recommandé de limiter les fonctions et droits inutiles, de protéger les fichiers sensibles et d’éviter de placer des secrets directement dans le code source.

Les mots de passe de base de données, clés API et autres secrets doivent être stockés dans une configuration adaptée ou dans un gestionnaire de secrets.

Contrôler les droits d’accès

L’OWASP Top 10 2025 place le Broken Access Control en première position des risques applicatifs. OWASP Top 10

L’application doit donc vérifier les droits côté serveur à chaque action sensible.

Il ne suffit pas de masquer un bouton dans l’interface.

Si un utilisateur demande directement une URL ou modifie un identifiant dans une requête, le serveur doit vérifier qu’il possède réellement le droit d’accéder à la ressource concernée.

Le principe du moindre privilège doit également s’appliquer aux comptes de base de données et aux services utilisés par l’application.

Intégrer la sécurité au cycle de développement

L’ancienne fiche recommandait principalement Grep et Tokenizer pour analyser le code. Ces outils peuvent encore servir pour des recherches ponctuelles, mais ils ne suffisent plus à eux seuls. Inforisque

Une démarche actuelle associe plusieurs contrôles :

1. revue du code par les développeurs ;
2. analyse statique du code ;
3. contrôle des dépendances ;
4. tests automatisés ;
5. tests de sécurité ;
6. revue des droits d’accès ;
7. analyse des logs ;
8. audits ou tests d’intrusion lorsque le contexte le justifie.

Les outils automatisés permettent d’identifier rapidement certaines anomalies. Cependant, ils ne remplacent pas la revue manuelle et la compréhension du fonctionnement réel de l’application.

Quels risques surveiller en priorité ?

L’OWASP Top 10 constitue une référence utile pour structurer la démarche de sécurité applicative. Sa version 2025 identifie notamment les catégories suivantes : contrôle d’accès défaillant, mauvaise configuration de sécurité, risques liés à la chaîne logicielle, défaillances cryptographiques, injections, conception non sécurisée, défauts d’authentification, problèmes d’intégrité du logiciel ou des données, insuffisance des journaux et alertes et mauvaise gestion des situations exceptionnelles. OWASP Top 10

Pour une application PHP, cela conduit notamment à surveiller :

Risque	Mesures prioritaires
Injection SQL	Requêtes préparées, validation
XSS	Encodage des sorties, templates sécurisés, CSP
CSRF	Jetons CSRF, SameSite
Vol de session	Cookies Secure/HttpOnly, rotation d’ID
Mauvais contrôle d’accès	Vérification serveur systématique
Dépendance vulnérable	Mises à jour et contrôle Composer
Mauvaise configuration	Configuration PHP et serveur durcie
Fuite d’informations	Logs internes, erreurs masquées en production
Compte compromis	Authentification robuste, limitation des privilèges
Failures de journalisation	Logs et alertes adaptés

Un audit de sécurité PHP ne doit pas se limiter au code

La sécurité d’une application PHP forme un ensemble.

Il faut contrôler le code, mais également :

• la version de PHP ;
• les extensions installées ;
• le serveur web ;
• la base de données ;
• les dépendances ;
• les droits utilisateurs ;
• les secrets ;
• les en-têtes HTTP ;
• la journalisation ;
• le déploiement.

Une faille peut apparaître à chacun de ces niveaux.

C’est pourquoi il est préférable d’intégrer les contrôles de sécurité tout au long du développement plutôt que d’attendre un audit final.