{"id":1394,"date":"2026-11-03T09:00:00","date_gmt":"2026-11-03T08:00:00","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1394"},"modified":"2026-11-03T09:02:50","modified_gmt":"2026-11-03T08:02:50","slug":"mises-a-jour-securite-laravel","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/fr\/2026\/11\/03\/mises-a-jour-securite-laravel\/","title":{"rendered":"Mises \u00e0 jour s\u00e9curit\u00e9 Laravel : comment je les surveille"},"content":{"rendered":"\n

Je g\u00e8re plusieurs serveurs de production. La majeure partie du trafic qui passe par mes h\u00e9bergements 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\u00e8gles non standard, le CMS ne suffit plus. C’est l\u00e0 qu’interviennent les frameworks PHP. Pour les mises \u00e0 jour s\u00e9curit\u00e9 Laravel<\/strong>, j’ai mis en place un contr\u00f4le que je fais vraiment tourner, pas seulement en th\u00e9orie.<\/p>\n\n\n\n

\"mises<\/figure>\n\n\n\n

Combien de sites sont des CMS et combien sont des applications sur mesure<\/h2>\n\n\n\n

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\u00e9, n’utilise aucun des CMS que ces statistiques suivent. On y trouve des sites statiques, mais aussi \u00e9norm\u00e9ment d’applications sur mesure. Ce n’est pas une donn\u00e9e parfaite. \u00ab\u00a0Aucun CMS d\u00e9tect\u00e9\u00a0\u00bb n’\u00e9quivaut pas exactement \u00e0 \u00ab\u00a0application sur mesure\u00a0\u00bb. Mais la direction est claire : les web apps faites \u00e0 la main restent une part \u00e9norme d’internet.<\/p>\n\n\n\n

Parmi les frameworks PHP utilis\u00e9s pour ces applications, Laravel est aujourd’hui le plus r\u00e9pandu. Le sondage State of PHP 2025 de JetBrains, men\u00e9 aupr\u00e8s de plus de 1 700 d\u00e9veloppeurs, rapporte 64% d’utilisation pour Laravel. Symfony suit, mais loin derri\u00e8re. Sur mes h\u00e9bergements, la situation est coh\u00e9rente avec cette tendance. Les applications sur mesure que je g\u00e8re pour mes clients, quand ce n’est pas du WordPress, sont presque toujours des projets Laravel. Certains clients arrivent d\u00e9j\u00e0 avec un projet existant \u00e0 maintenir. D’autres me le demandent de z\u00e9ro, sachant que c’est le choix le plus courant sur le march\u00e9. Les d\u00e9comptes absolus de sites, venant de sources comme BuiltWith, sont \u00e0 prendre avec pr\u00e9caution : Laravel int\u00e8gre en son sein plusieurs composants de Symfony, ce qui brouille un peu les statistiques bas\u00e9es uniquement sur les paquets install\u00e9s. Mais le tableau g\u00e9n\u00e9ral ne change pas : pour qui \u00e9crit des applications PHP sur mesure, Laravel est aujourd’hui le point de d\u00e9part le plus courant, pas l’exception.<\/p>\n\n\n\n

Comment je surveille les mises \u00e0 jour s\u00e9curit\u00e9 Laravel<\/h2>\n\n\n\n

Un projet Laravel en production n’est jamais \u00ab\u00a0termin\u00e9 et fig\u00e9\u00a0\u00bb. Le framework, ses composants et les dizaines de paquets Composer qu’il apporte avec lui re\u00e7oivent des correctifs quand une faille est d\u00e9couverte. Si personne ne v\u00e9rifie, un site peut rester vuln\u00e9rable pendant des mois. Le client ne s’en aper\u00e7oit souvent m\u00eame pas. C’est le m\u00eame principe que j’ai appliqu\u00e9 quand j’ai d\u00fb g\u00e9rer une attaque en cours sur un serveur pendant une urgence de s\u00e9curit\u00e9 PHP<\/a> : mieux vaut pr\u00e9venir avec un contr\u00f4le r\u00e9gulier, que courir apr\u00e8s le probl\u00e8me une fois qu’il a d\u00e9j\u00e0 \u00e9clat\u00e9.<\/p>\n\n\n\n

Pour cela, j’ai \u00e9crit un script bash simple. Je le fais tourner via cron sur chaque projet Laravel que je g\u00e8re. Je l’int\u00e8gre aussi dans les pipelines de d\u00e9ploiement, 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\u00e9es de vuln\u00e9rabilit\u00e9s connues. Le voici, exactement comme je l’utilise, sans modification.<\/p>\n\n\n\n

Le script d’audit<\/h3>\n\n\n\n
#!\/usr\/bin\/env bash\nset -euo pipefail\n\nPROJECT_DIR=\"${1:-.}\"\ncd \"$PROJECT_DIR\"\n\necho \"==> Project: $(pwd)\"\n\nif [[ ! -f composer.lock ]]; then\n  echo \"SKIP: composer.lock non trovato (non sembra un progetto composer installato).\"\n  exit 0\nfi\n\necho \"\"\necho \"==> Composer audit (vulnerabilit\u00e0 note)\"\n# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory\ncomposer audit --no-interaction\n\necho \"\"\necho \"==> Pacchetti outdated (info)\"\ncomposer outdated --direct || true\n\necho \"\"\necho \"==> Laravel version (se presente)\"\nphp -r '\n$lock=json_decode(file_get_contents(\"composer.lock\"), true);\n$pkgs=array_merge($lock[\"packages\"] ?? [], $lock[\"packages-dev\"] ?? []);\n$laravel=null;\nforeach ($pkgs as $p) { if (($p[\"name\"] ?? \"\")===\"laravel\/framework\") { $laravel=$p[\"version\"] ?? null; break; } }\necho $laravel ? \"laravel\/framework: $laravel\\n\" : \"laravel\/framework non trovato nel lock\\n\";\n'\n<\/code><\/pre>\n\n\n\n
Avertissement<\/strong> : le script est fourni tel quel, \u00e0 titre informatif. Son utilisation se fait enti\u00e8rement \u00e0 vos risques : je n’assume aucune responsabilit\u00e9 pour une perte de donn\u00e9es, une interruption de service, ou toute erreur caus\u00e9e par un usage incorrect ou par un contexte diff\u00e9rent de celui dans lequel je l’utilise moi-m\u00eame. Gardez toujours une sauvegarde ind\u00e9pendante avant de l’ex\u00e9cuter en production.<\/p>\n\n\n\n
composer audit<\/code> est une commande int\u00e9gr\u00e9e \u00e0 Composer depuis la version 2.4. Il lit les versions exactes des paquets pr\u00e9sents dans composer.lock<\/code>. Il les compare \u00e0 une base de donn\u00e9es d’advisories de s\u00e9curit\u00e9 publi\u00e9es. Cette base arrive via Packagist, qui s’appuie \u00e0 son tour sur le d\u00e9p\u00f4t FriendsOfPHP\/security-advisories et sur le GitHub Advisory Database. S’il trouve une correspondance, il liste le paquet, la version vuln\u00e9rable et l’advisory associ\u00e9. Puis il se termine avec un code de sortie diff\u00e9rent de z\u00e9ro. C’est ce d\u00e9tail qui m’int\u00e9resse le plus. Un exit code non nul est ce qui permet \u00e0 un cron ou \u00e0 une pipeline de comprendre seul que quelque chose doit \u00eatre revu. Je n’ai pas besoin de lire chaque ligne de log \u00e0 la main.<\/p>\n\n\n\n
Sur les projets en production, je le lance une fois par jour via cron, avec la sortie envoy\u00e9e par email si la commande \u00e9choue. Sur certains clients plus structur\u00e9s, je l’ai aussi int\u00e9gr\u00e9 \u00e0 la pipeline de d\u00e9ploiement. Si composer audit<\/code> trouve un advisory bloquant, le d\u00e9ploiement s’arr\u00eate avant d’arriver en production. Mieux vaut s’arr\u00eater l\u00e0 que le d\u00e9couvrir apr\u00e8s, le site d\u00e9j\u00e0 en ligne. Ce contr\u00f4le quotidien, r\u00e9p\u00e9t\u00e9 sur chaque projet, est le c\u0153ur pratique des mises \u00e0 jour s\u00e9curit\u00e9 Laravel que j’applique vraiment, pas seulement quand je pense \u00e0 le faire \u00e0 la main.<\/p>\n\n\n\n
La deuxi\u00e8me ligne du script, composer outdated --direct<\/code>, montre seulement les d\u00e9pendances d\u00e9clar\u00e9es \u00e0 la main dans le composer.json<\/code>. Elle ne montre pas tout l’arbre des d\u00e9pendances 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\u00e9pendances directes, je vois d’un coup d’\u0153il ce que j’ai choisi moi-m\u00eame. Je peux d\u00e9cider calmement quoi mettre \u00e0 jour et quand le faire.<\/p>\n\n\n\n
La derni\u00e8re partie du script affiche la version de laravel\/framework<\/code> pr\u00e9sente dans le lock file. Je le fais parce que le cycle de vie des versions Laravel a des \u00e9ch\u00e9ances pr\u00e9cises. Je veux les conna\u00eetre sans ouvrir chaque projet \u00e0 la main, un par un. Selon le tableau officiel de support publi\u00e9 par Laravel, les correctifs de s\u00e9curit\u00e9 pour la version 11 se sont termin\u00e9s le 12 mars 2026. La version 12 les re\u00e7oit jusqu’au 24 f\u00e9vrier 2027. Depuis le premier trimestre 2026, la version courante est Laravel 13. Planifier les mises \u00e0 jour s\u00e9curit\u00e9 Laravel \u00e0 temps, c’est aussi \u00e7a : savoir sur quelle version chaque projet est bloqu\u00e9, avant que le support n’expire.<\/p>\n\n\n\n
Les limites honn\u00eates de ce contr\u00f4le<\/h2>\n\n\n\n
composer audit<\/code> n’est pas un antivirus. Il ne lit pas le code de l’application. Il signale seulement des vuln\u00e9rabilit\u00e9s connues et d\u00e9j\u00e0 publi\u00e9es dans un advisory. Contre une faille zero-day, d\u00e9couverte mais pas encore divulgu\u00e9e, il ne sert \u00e0 rien. Pour cette raison, je le consid\u00e8re comme un contr\u00f4le d’hygi\u00e8ne de base, pas comme une garantie absolue. Les mises \u00e0 jour r\u00e9guli\u00e8res des paquets<\/a> restent la pratique la plus efficace, m\u00eame 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 \u00e0 jour majeure. Cela sert \u00e0 faire de la mise \u00e0 jour une habitude, pas une urgence de derni\u00e8re minute.<\/p>\n\n\n\n
Il reste que ce script de quelques lignes, lanc\u00e9 chaque jour, m’aurait \u00e9vit\u00e9 plus d’un email embarrassant \u00e0 mes clients, dans les ann\u00e9es o\u00f9 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 \u00e0 la surveillance des logs et des tentatives d’acc\u00e8s sur les serveurs. Les mises \u00e0 jour s\u00e9curit\u00e9 Laravel n’\u00e9liminent pas le risque. Elles le r\u00e9duisent beaucoup. Et elles co\u00fbtent tr\u00e8s peu, compar\u00e9 \u00e0 un site compromis et un client qui perd confiance.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
Comment je surveille les mises \u00e0 jour s\u00e9curit\u00e9 Laravel sur mes projets, avec un script bash lanc\u00e9 via cron et int\u00e9gr\u00e9 aux pipelines de d\u00e9ploiement.<\/p>\n","protected":false},"author":1,"featured_media":1388,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[362],"tags":[517,372,518,516,377,341],"class_list":["post-1394","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-serveurs-bases-de-donnees","tag-composer","tag-gestion-de-serveurs","tag-laravel","tag-mise-a-jour","tag-php-fr","tag-script-bash-fr"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t