Je gère plusieurs serveurs de production. La majeure partie du trafic qui passe par mes hébergements va vers des sites WordPress. Mais pas tout. Quand un client me demande un outil de gestion sur mesure, un backend pour une app, ou une petite boutique en ligne avec des règles non standard, le CMS ne suffit plus. C’est là qu’interviennent les frameworks PHP. Pour les mises à jour sécurité Laravel, j’ai mis en place un contrôle que je fais vraiment tourner, pas seulement en théorie.
Combien de sites sont des CMS et combien sont des applications sur mesure
Les chiffres de W3Techs indiquent qu’environ 68% des sites avec un CMS reconnu utilisent WordPress, Shopify ou une plateforme similaire. Le reste, un peu plus d’un tiers du web public surveillé, n’utilise aucun des CMS que ces statistiques suivent. On y trouve des sites statiques, mais aussi énormément d’applications sur mesure. Ce n’est pas une donnée parfaite. « Aucun CMS détecté » n’équivaut pas exactement à « application sur mesure ». Mais la direction est claire : les web apps faites à la main restent une part énorme d’internet.
Parmi les frameworks PHP utilisés pour ces applications, Laravel est aujourd’hui le plus répandu. Le sondage State of PHP 2025 de JetBrains, mené auprès de plus de 1 700 développeurs, rapporte 64% d’utilisation pour Laravel. Symfony suit, mais loin derrière. Sur mes hébergements, la situation est cohérente avec cette tendance. Les applications sur mesure que je gère pour mes clients, quand ce n’est pas du WordPress, sont presque toujours des projets Laravel. Certains clients arrivent déjà avec un projet existant à maintenir. D’autres me le demandent de zéro, sachant que c’est le choix le plus courant sur le marché. Les décomptes absolus de sites, venant de sources comme BuiltWith, sont à prendre avec précaution : Laravel intègre en son sein plusieurs composants de Symfony, ce qui brouille un peu les statistiques basées uniquement sur les paquets installés. Mais le tableau général ne change pas : pour qui écrit des applications PHP sur mesure, Laravel est aujourd’hui le point de départ le plus courant, pas l’exception.
Comment je surveille les mises à jour sécurité Laravel
Un projet Laravel en production n’est jamais « terminé et figé ». Le framework, ses composants et les dizaines de paquets Composer qu’il apporte avec lui reçoivent des correctifs quand une faille est découverte. Si personne ne vérifie, un site peut rester vulnérable pendant des mois. Le client ne s’en aperçoit souvent même pas. C’est le même principe que j’ai appliqué quand j’ai dû gérer une attaque en cours sur un serveur pendant une urgence de sécurité PHP : mieux vaut prévenir avec un contrôle régulier, que courir après le problème une fois qu’il a déjà éclaté.
Pour cela, j’ai écrit un script bash simple. Je le fais tourner via cron sur chaque projet Laravel que je gère. Je l’intègre aussi dans les pipelines de déploiement, quand le client en a une. Il ne fait pas de miracle : il lit le fichier de lock de Composer et le compare aux bases de données de vulnérabilités connues. Le voici, exactement comme je l’utilise, sans modification.
Le script d’audit
#!/usr/bin/env bash
set -euo pipefail
PROJECT_DIR="${1:-.}"
cd "$PROJECT_DIR"
echo "==> Project: $(pwd)"
if [[ ! -f composer.lock ]]; then
echo "SKIP: composer.lock non trovato (non sembra un progetto composer installato)."
exit 0
fi
echo ""
echo "==> Composer audit (vulnerabilità note)"
# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory
composer audit --no-interaction
echo ""
echo "==> Pacchetti outdated (info)"
composer outdated --direct || true
echo ""
echo "==> Laravel version (se presente)"
php -r '
$lock=json_decode(file_get_contents("composer.lock"), true);
$pkgs=array_merge($lock["packages"] ?? [], $lock["packages-dev"] ?? []);
$laravel=null;
foreach ($pkgs as $p) { if (($p["name"] ?? "")==="laravel/framework") { $laravel=$p["version"] ?? null; break; } }
echo $laravel ? "laravel/framework: $laravel\n" : "laravel/framework non trovato nel lock\n";
'
Avertissement : le script est fourni tel quel, à titre informatif. Son utilisation se fait entièrement à vos risques : je n’assume aucune responsabilité pour une perte de données, une interruption de service, ou toute erreur causée par un usage incorrect ou par un contexte différent de celui dans lequel je l’utilise moi-même. Gardez toujours une sauvegarde indépendante avant de l’exécuter en production.
composer audit est une commande intégrée à Composer depuis la version 2.4. Il lit les versions exactes des paquets présents dans composer.lock. Il les compare à une base de données d’advisories de sécurité publiées. Cette base arrive via Packagist, qui s’appuie à son tour sur le dépôt FriendsOfPHP/security-advisories et sur le GitHub Advisory Database. S’il trouve une correspondance, il liste le paquet, la version vulnérable et l’advisory associé. Puis il se termine avec un code de sortie différent de zéro. C’est ce détail qui m’intéresse le plus. Un exit code non nul est ce qui permet à un cron ou à une pipeline de comprendre seul que quelque chose doit être revu. Je n’ai pas besoin de lire chaque ligne de log à la main.
Sur les projets en production, je le lance une fois par jour via cron, avec la sortie envoyée par email si la commande échoue. Sur certains clients plus structurés, je l’ai aussi intégré à la pipeline de déploiement. Si composer audit trouve un advisory bloquant, le déploiement s’arrête avant d’arriver en production. Mieux vaut s’arrêter là que le découvrir après, le site déjà en ligne. Ce contrôle quotidien, répété sur chaque projet, est le cœur pratique des mises à jour sécurité Laravel que j’applique vraiment, pas seulement quand je pense à le faire à la main.
La deuxième ligne du script, composer outdated --direct, montre seulement les dépendances déclarées à la main dans le composer.json. Elle ne montre pas tout l’arbre des dépendances transitives. Un projet Laravel moyen apporte avec lui des centaines de paquets indirects. Si je les listais tous, la sortie serait illisible. Je finirais par l’ignorer, comme cela arrive avec trop d’alertes automatiques. En ne regardant que les dépendances directes, je vois d’un coup d’œil ce que j’ai choisi moi-même. Je peux décider calmement quoi mettre à jour et quand le faire.
La dernière partie du script affiche la version de laravel/framework présente dans le lock file. Je le fais parce que le cycle de vie des versions Laravel a des échéances précises. Je veux les connaître sans ouvrir chaque projet à la main, un par un. Selon le tableau officiel de support publié par Laravel, les correctifs de sécurité pour la version 11 se sont terminés le 12 mars 2026. La version 12 les reçoit jusqu’au 24 février 2027. Depuis le premier trimestre 2026, la version courante est Laravel 13. Planifier les mises à jour sécurité Laravel à temps, c’est aussi ça : savoir sur quelle version chaque projet est bloqué, avant que le support n’expire.
Les limites honnêtes de ce contrôle
composer audit n’est pas un antivirus. Il ne lit pas le code de l’application. Il signale seulement des vulnérabilités connues et déjà publiées dans un advisory. Contre une faille zero-day, découverte mais pas encore divulguée, il ne sert à rien. Pour cette raison, je le considère comme un contrôle d’hygiène de base, pas comme une garantie absolue. Les mises à jour régulières des paquets restent la pratique la plus efficace, même sans advisory en cours. La documentation officielle de Laravel recommande de rester sur la version courante du framework. Elle recommande aussi d’automatiser les tests avant chaque mise à jour majeure. Cela sert à faire de la mise à jour une habitude, pas une urgence de dernière minute.
Il reste que ce script de quelques lignes, lancé chaque jour, m’aurait évité plus d’un email embarrassant à mes clients, dans les années où je ne l’utilisais pas encore. Aujourd’hui, il fait partie de la routine de maintenance de chaque projet Laravel que je suis. Je l’associe à la surveillance des logs et des tentatives d’accès sur les serveurs. Les mises à jour sécurité Laravel n’éliminent pas le risque. Elles le réduisent beaucoup. Et elles coûtent très peu, comparé à un site compromis et un client qui perd confiance.
Laisser un commentaire