Blog / Article #148

Sécurité PHP au-delà des CVEs : arrêter de courir après les failles, c'est possible ?

On connaît tous ça : le matin, on boit notre café, et paf, une nouvelle CVE critique pour PHP. On se précipite pour patcher, on croise les doigts, et on espère que ça tiendra jusqu'à la prochaine alerte. Mais franchement, cette course perpétuelle, c'est épuisant et pas très efficace. Et si on arrêtait de juste réagir pour commencer à anticiper ?

L'idée, ce n'est pas de devenir paranoïaque ou d'attendre la 0-day qui va tout casser. C'est plutôt d'intégrer la sécurité comme une composante à part entière de notre workflow de dev, de la conception au déploiement. Moins de stress, plus de robustesse. Ça vous tente ?

Comprendre les risques : un ennemi aux mille visages

Avant de blinder, il faut savoir ce qu'on blinde. Les vulnérabilités PHP sont variées et évoluent constamment. On parle de RCE (Remote Code Execution), le cauchemar de tout dev, mais aussi des injections SQL classiques, des XSS (Cross-Site Scripting), des Use-After-Free (UAF) plus bas niveau dans l'interpréteur... La liste est longue et chaque faille peut avoir des conséquences désastreuses. Le but n'est pas de devenir un expert en exploit, mais de comprendre que chaque interaction avec l'extérieur est une porte potentielle.

Votre workflow de mise à jour : l'automatisation, votre meilleure amie

La première ligne de défense, c'est de garder votre environnement et vos dépendances à jour. Mais le faire à la main, c'est lourd et source d'erreurs. Heureusement, il y a des outils.

Composer Audit : le gendarme de vos dépendances

Mon premier réflexe, c'est composer audit. C'est intégré à Composer depuis la version 2.4, donc si vous êtes à jour, vous l'avez déjà. Cette commande scanne votre fichier composer.lock et vous dit si vos paquets installés contiennent des vulnérabilités de sécurité connues. Simple, rapide, et ça peut vous sauver la mise avant même de déployer.

composer audit

Pour exclure les dépendances de dev (souvent moins critiques en production) :

composer audit --no-dev

Vous pouvez même ignorer des avis spécifiques directement dans votre composer.json si vous avez de bonnes raisons (mais faites-le avec parcimonie et en connaissance de cause !) :

{
    "config": {
        "audit": {
            "ignore": {
                "CVE-2024-XXXXX": "Raison de l'ignorance",
                "GHSA-xxxx-yyyy": "Autre raison"
            }
        }
    }
}

Pour aller plus loin et bloquer carrément l'installation de paquets vulnérables, j'utilise parfois roave/security-advisories. C'est un méta-paquet Composer qui empêche l'installation de paquets avec des vulnérabilités connues en les listant comme des conflits. Très efficace pour durcir votre CI/CD.

Dependabot : les PR de sécurité, sans effort

Pour ne pas avoir à lancer composer audit à la main tous les jours, il y a Dependabot. Intégré à GitHub, il vous crée des pull requests automatiquement pour les mises à jour de sécurité et de version de vos dépendances PHP (et d'autres écosystèmes). Un fichier .github/dependabot.yml dans votre dépôt, et le tour est joué.

version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "daily"

Vous pouvez affiner la configuration pour grouper les mises à jour, ignorer certaines versions majeures, etc. C'est un gain de temps considérable et ça assure que vous êtes alerté dès qu'une nouvelle version corrigeant une faille est disponible.

Hardening du runtime PHP : blinder l'environnement

Au-delà de votre code, l'environnement d'exécution de PHP est crucial. Je pense bien sûr à la configuration de php.ini. Des directives comme disable_functions pour désactiver des fonctions dangereuses (comme exec, shell_exec, passthru), open_basedir pour restreindre l'accès aux fichiers, ou encore expose_php = Off pour ne pas annoncer la version de PHP et donner des indices aux attaquants. C'est du basique, mais trop souvent oublié.

Côté serveur, que vous soyez sur Nginx avec PHP-FPM ou Apache, assurez-vous que PHP-FPM s'exécute avec des droits minimaux, que les répertoires web sont configurés correctement pour ne pas exécuter de scripts dans les dossiers d'upload, et que les en-têtes de sécurité sont bien en place (CSP, HSTS, X-Content-Type-Options, etc.). Chaque couche compte.

Sécurité au niveau de l'application : code, dépendances et analyse statique

C'est là que le gros du travail se fait, dans votre code et vos pratiques de développement.

Analyse Statique (SAST) : les yeux de lynx pour votre code

Les outils d'analyse statique sont des alliés précieux pour trouver des failles avant même de lancer le code. Ils ne remplacent pas les tests, mais les complètent magnifiquement.

Psalm : le traqueur de taint

Pour l'analyse statique, Psalm est un de mes outils préférés. Il ne fait pas que du type-checking avancé, il excelle aussi dans l'analyse de taint (--taint-analysis). En gros, il traque les données venant de l'extérieur (vos $_GET, $_POST, $_COOKIE...) jusqu'à des points sensibles (des 'sinks' comme un echo direct sans échappement ou une requête SQL non préparée). Ça demande un peu de configuration pour éviter les faux positifs, mais ça vaut le coup pour débusquer les XSS ou les injections SQL que vous auriez pu rater.

composer require --dev vimeo/psalm
./vendor/bin/psalm --init
./vendor/bin/psalm --taint-analysis

PHPStan : le garant de la justesse

PHPStan est un autre mastodonte de l'analyse statique. Moins axé sur la sécurité par défaut que Psalm pour l'analyse de taint, il est redoutable pour la justesse du code, la vérification des types et la détection de bugs subtils. Il reste un incontournable pour la qualité générale et la robustesse de votre application.

composer require --dev phpstan/phpstan
./vendor/bin/phpstan analyse --level 5 src

SonarQube et Semgrep : pour les grands projets (ou les grands principes)

Pour des projets plus gros ou des équipes, des plateformes comme SonarQube offrent une vision globale de la qualité et de la sécurité. SonarSource a même intégré RIPS, un moteur SAST PHP très puissant. Semgrep, lui, est plus léger et flexible, parfait pour des règles de sécurité personnalisées ou des intégrations CI/CD rapides.

Bonnes pratiques de code et bibliothèques sécurisées

Même les meilleurs outils ne remplacent pas de bonnes habitudes de codage.

• Cryptographie : En matière de cryptographie, ne réinventez jamais la roue. Utilisez l'extension PHP ext-sodium si possible, ou son polyfill paragonie/sodium_compat. C'est maintenu par des experts et ça évite des erreurs coûteuses.

composer require paragonie/sodium_compat

• Frameworks : Si vous utilisez un framework comme Symfony ou Laravel, exploitez leurs fonctionnalités de sécurité intégrées. Symfony a son SecurityBundle pour l'authentification/autorisation et NelmioSecurityBundle pour la Content-Security-Policy (CSP) et la gestion des cookies. Laravel, de son côté, intègre directement la protection XSS/CSRF, les requêtes préparées via Eloquent, le hachage des mots de passe avec Bcrypt/Argon2, et un système d'authentification robuste. Utilisez-les à bon escient et ne les contournez pas !

Monitoring et alertes : le filet de sécurité

Même avec toutes ces précautions, une faille peut toujours passer. Mettre en place du monitoring et des alertes est crucial. Surveillez les logs d'accès, les erreurs PHP, les tentatives d'authentification échouées. Des outils de SIEM (Security Information and Event Management) ou des solutions de détection d'intrusion peuvent vous alerter en cas de comportement suspect, avant qu'un attaquant ne fasse trop de dégâts. L'objectif est de détecter une tentative d'exploitation le plus tôt possible, idéalement avant qu'elle ne soit fructueuse.

Conclusion : vers une culture de la sécurité intégrée

La sécurité n'est pas un sprint, c'est un marathon. Ça demande un effort constant, mais en intégrant ces pratiques proactives dans votre workflow de développement, vous ne courrez plus après les CVEs. Vous construisez des applications plus robustes, plus sereines, et vous dormez mieux la nuit. Alors, on s'y met ?