Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Une attaque contre Packagist survenue en mai 2026 a démontré qu'un simple numéro de version ne suffit pas à garantir la fiabilité d'une installation via Composer.
- Laravel 13 est entièrement pris en charge, Laravel 12 ne bénéficie plus que de correctifs de sécurité, et toutes les versions antérieures ont atteint leur fin de vie.
- La vulnérabilité CVE-2026-48019 affecte toutes les versions de Laravel antérieures à la version 12.60.0, ainsi que les versions de Laravel 13 antérieures à la version 13.10.0.
- La plupart des risques liés à Laravel résident dans les options de désactivation, les requêtes brutes et les dépendances que personne n'a mises à jour.
La sécurité de Laravel dépend moins du framework lui-même que de ce qui se passe après son installation. Un paramètre par défaut désactivé, une requête non sécurisée ou une dépendance que personne n'a mise à jour suffisent généralement à créer une faille.
Ce guide passe en revue les menaces qui continuent d'affecter les environnements de production, les mesures permettant de les contrer, la manière de sécuriser vos API et les mesures à prendre si vous êtes contraint d'utiliser une version en fin de vie.
Pourquoi la sécurité est-elle importante dans les applications Laravel ?
Une seule faille de sécurité peut anéantir des années de confiance client, entraîner une responsabilité juridique et fournir aux pirates les identifiants d'accès au serveur qui leur ouvrent la porte à tous vos autres systèmes. Et les modes d'intrusion ont évolué. Le rapport DBIR 2026 de Verizon a révélé que l’exploitation d’une vulnérabilité est désormais le vecteur d’accès initial le plus courant pour les violations de données, apparaissant dans 31 % des cas, contre 20 % l’année précédente, tandis que l’utilisation abusive des identifiants a chuté à 13 %.
Laravel élimine d’emblée toute une catégorie de problèmes dès son installation. Eloquent paramétrise les valeurs des requêtes, Blade échappe les données de sortie par défaut, et le middleware de protection contre la falsification de requêtes (RFF) est intégré au groupe « web » sans que personne ne l’ait demandé. Rien de tout cela ne résiste si un développeur décide de le désactiver, et rien de tout cela ne couvre l’autorisation, les erreurs de configuration, la falsification de requêtes côté serveur, la logique métier ou une dépendance vulnérable. Ces aspects restent votre responsabilité, pour toujours.
Menaces courantes pour la sécurité de Laravel
Exécution de scripts intersites via une sortie Blade non échappée
Blade’s {{ }} synthèse échappe automatiquement la sortie. Le syntaxe {!! !!} ne le fait pas, et c’est celle que les utilisateurs privilégient lorsqu’ils ont besoin d’afficher du code HTML stocké provenant d’un champ de CMS ou d’un éditeur de texte enrichi.
Si ce code HTML stocké contient une balise script, celle-ci s'exécute dans le navigateur de tous les utilisateurs qui chargent la page. Il faut donc le nettoyer au préalable côté serveur, à l'aide d'une bibliothèque telle que HTMLPurifier, avant même qu'il n'atteigne {!! !!}.
Injection SQL via des expressions brutes
Eloquent et le générateur de requêtes paramétrent les valeurs des requêtes ; les injections ne constituent donc pas un risque pour les requêtes classiques. Le problème réapparaît dès que les données saisies par l’utilisateur sont concaténées dans DB::raw(), où Raw(), havingRaw(), ou orderByRaw().
Les noms de colonnes et de directions sont souvent oubliés, car ils ne peuvent pas être passés en paramètres. Il vaut mieux les ajouter à une liste autorisée par rapport à un tableau fixe. Cela n'a d'ailleurs rien de spécifique à Laravel. C'est la même erreur que les développeurs PHP commettent depuis vingt ans avec les requêtes SQL construites à partir de chaînes de caractères.
Problèmes d'authentification et de gestion des sessions
Le framework d'authentification de Laravel est solide. Les problèmes se situent plutôt au niveau de ses éléments connexes : absence de limitation de débit lors de la connexion, jetons de réinitialisation qui n'expirent jamais, sessions qui ne se régénèrent pas après un changement de privilèges, et processus personnalisés de modification de mot de passe qui ignorent la méthode `setRememberToken`, ce qui rend les sessions « se souvenir de moi » toujours valides après le changement de mot de passe.
Vérifier l'autorisation indépendamment de l'authentification. Une connexion fonctionnelle qui permet à tout utilisateur authentifié d'accéder à /admin constitue une faille d'autorisation, et non un bug du formulaire de connexion.
Meilleures pratiques en matière de sécurité avec Laravel
1. Veillez à ce que Laravel et ses dépendances soient toujours à jour
Exécuter composer outdated toutes les semaines ou toutes les deux semaines pour voir quels paquets ont des versions plus récentes, puis « composer update » pour les récupérer en respectant les contraintes que vous avez définies dans le fichier composer.json. Gardez un œil sur les notes de mise à jour de Laravel et les avis de sécurité sur GitHub , car c’est là que les nouvelles vulnérabilités du framework sont signalées en premier.
La politique actuelle de Laravel prévoit, pour chaque version, 18 mois de corrections de bogues et deux ans de correctifs de sécurité à compter de sa date de sortie. Il n'y a plus non plus de version LTS. Laravel 6 a été la dernière, et les délais ont varié lors du passage des versions mineures semestrielles aux versions majeures annuelles, ce qui explique pourquoi les anciennes lignes ci-dessous ne suivent pas toutes le même schéma.
| Version | Date de sortie | Corrections de bogues jusqu’au | Correctifs de sécurité jusqu’au |
| 13 | Mars 17, 2026 | Q3 2027 | Mars 17, 2028 |
| 12 | Février 24, 2025 | Août 13, 2026 | Février 24, 2027 |
| 11 | Mars 12, 2024 | Septembre 3, 2025 | Mars 12, 2026 |
| 10 | Février 14, 2023 | Août 6, 2024 | Février 4, 2025 |
| 9 | Février 8, 2022 | Août 8, 2023 | Février 6, 2024 |
| 8 | Septembre 8, 2020 | Juillet 26, 2022 | Janvier 24, 2023 |
| 7 | Mars 3, 2020 | Octobre 6, 2020 | Mars 3, 2021 |
| 6 (LTS) | Septembre 3, 2019 | Janvier 25, 2022 | Septembre 6, 2022 |
| 5.8 | Février 26, 2019 | Août 26, 2019 | Février 26, 2020 |
| 5.7 | Septembre 4, 2018 | Mars 4, 2019 | Septembre 4, 2019 |
| 5.6 | Février 7, 2018 | Août 7, 2018 | Février 7, 2019 |
| 5.5 (LTS) | Août 30, 2017 | Août 30, 2019 | Août 30, 2020 |
| 5.4 | Janvier 24, 2017 | Juillet 24, 2017 | Janvier 24, 2018 |
CVE-2026-48019 illustre le prix à payer lorsqu'on prend du retard. Il s'agit d'une injection CRLF dans la règle de validation par défaut des e-mails de Laravel qui, combinée à la manière dont Symfony Mailer et Symfony Mime traitent certaines séquences de caractères, permet à un attaquant non authentifié de falsifier les e-mails sortants, en y insérant un en-tête Bcc, en modifiant le contenu du message ou en transformant l'application en relais. L'avis de sécurité indique que toutes les versions antérieures à la 12.60.0 sont concernées, ainsi que Laravel 13 jusqu'à la version 13.9.0, et que les correctifs ont été intégrés dans les versions 12.60.0 et 13.10.0. La fenêtre de sécurité de Laravel 11 s'était déjà refermée en mars 2026 ; par conséquent, la version 11 et toutes les branches antérieures se situent dans cette plage sans qu'aucune version corrigée n'ait été publiée par l'amont.
Si une mise à niveau majeure n'est pas envisageable pour le moment, le service « Endless Lifecycle Support » de TuxCare pour Laravel réintègre les correctifs de sécurité via Composer sur des versions de référence spécifiques, actuellement de la 5.4.36 à la 12.58.0, d’autres versions étant disponibles sur demande.
2. Considérer chaque demande de dérogation à une mesure de protection comme une étape de révision du code
Every Laravel security default ships with an escape hatch, and each one deserves a second pair of eyes before it goes out. {!! !!} in Blade turns off output escaping. DB::raw() and whereRaw() accept raw SQL, so any untrusted input has to arrive as a binding rather than concatenated into the string. Model::unguard(), $guarded = [],and Laravel 13’s #[Unguarded] attribute all open mass assignment on every column.
La protection contre la falsification des requêtes dispose de sa propre « porte de secours », et l'API a été déplacée. Sous Laravel 13, on exclut les routes à l'aide de preventRequestForgery(except: […]) dans bootstrap/app.php; sous les versions 11 et 12, la même méthode s’appelle validateCsrfTokens(), tandis que les versions antérieures utilisent la méthode $except de la classe de middleware CSRF. Une route peut également se désinscrire en transmettant la classe de middleware de protection contre la falsification de requêtes appropriée à withoutMiddleware().
Intégrez tous ces éléments à un contrôle CI basé sur grep, et demandez à l'auteur de toute pull request qui en introduit un d'expliquer dans la description pourquoi il s'y trouve.
3. Valider côté serveur et autoriser séparément
La validation permet de vérifier si les données sont correctement structurées. L'autorisation permet de vérifier si cet utilisateur est habilité à agir sur ces données. Le fait de réussir l'une n'implique en rien l'autre.
Utilisez des classes de requêtes de formulaire afin que les règles de validation soient centralisées dans un emplacement facilement consultable, et recourez à des « Policies » ou à des « Gates » pour chaque action du modèle. La validation côté client améliore l'expérience utilisateur, mais n'apporte absolument rien en matière de sécurité.
4. Sécurisation de la configuration et des secrets
Définir APP_DEBUG=false en environnement de production, sans exception. La documentation officielle de Laravel est très claire quant au risque lié au fait de laisser le mode débogage activé : des valeurs de configuration sensibles peuvent être exposées aux utilisateurs finaux, et la page d'erreur de débogage fournit des traces de pile détaillées à toute personne ayant déclenché l'erreur.
Conserver .env hors du contrôle de version, vérifiez que votre racine web pointe vers /public, puis renouvelez APP_KEY si elle a déjà été validée. Chaque valeur chiffrée et chaque cookie signé de l'application dépendent de cette clé ; veillez donc à répertorier l'ancienne clé dans le fichier APP_PREVIOUS_KEYS lorsque vous procédez à la rotation. Sans cela, les données précédemment chiffrées ne pourront plus être déchiffrées, et toutes les sessions authentifiées seront déconnectées.
5. Effectuer les audits de dépendance selon un calendrier préétabli, et non après la survenue d'incidents
Lancer un audit Composer dans l'environnement de CI afin qu'un paquet présentant une vulnérabilité connue fasse échouer la compilation plutôt que d'apparaître dans un rapport trimestriel.
composer audit –format=summary
Les paquets officiels de Laravel font également l'objet de CVE. CVE-2026-39976 correspondait à un contournement de l'authentification dans laravel/passport, corrigé dans la version 13.7.1, où une token client_credentials pouvait correspondre à un véritable compte utilisateur. Ce problème ne se pose que si les identifiants client UUID ont été désactivés, ce qui est précisément le genre de détail qui passe inaperçu lorsqu’un scanner se contente de signaler qu’un paquet a été identifié comme vulnérable. Associez les analyses planifiées à des audits de sécurité et un processus documenté de correction des vulnérabilités.
Attention : Les 22 et 23 mai 2026, un un pirate a republié du code malveillant sous des balises de version historiques pour quatre paquets Laravel-Lang sur Packagist. Toutes les balises existantes ont été redirigées vers un nouveau commit, de sorte que le numéro de version figurant dans votre fichier composer.json ne vous indiquait donc rien sur ce qui avait réellement été installé. Pour savoir si vous étiez concerné, il fallait vérifier le commit résolu dans composer.lock, au moment de l’exécution de vos builds, ainsi que les indicateurs de compromission publiés à l’époque.
Sécurisation des API Laravel
La plupart des API sont sans état et fonctionnent par jetons, ce qui modifie le modèle de sécurité plutôt que de simplement l’affaiblir. Un jeton « bearer » n’est pas ajouté automatiquement par le navigateur, contrairement à un cookie de session ; la protection contre les attaques CSRF cesse donc d’être le mécanisme de contrôle déterminant. Ce sont désormais l’authentification, l’autorisation à chaque action, une politique CORS correctement configurée, la limitation de débit et le cycle de vie des jetons qui jouent un rôle prépondérant. Les configurations avec état, comme le mode SPA de Sanctum, constituent l’exception, car elles utilisent des cookies de session et nécessitent une protection CSRF.
Il manque toutefois véritablement une chose. Personne n'est là pour surveiller les réponses ; ainsi, une attaque par énumération lente lancée contre une API peut se poursuivre pendant des jours avant que quelqu'un ne s'en aperçoive.
Choisissez délibérément entre « Sanctum » et « Passport »
Sanctum gère l'authentification par jeton et par SPA avec une configuration minimale et s'adapte à la plupart des applications. Passport implémente l'ensemble des fonctionnalités OAuth2 et n'est pertinent que lorsque vous avez réellement besoin de flux d'autorisation tiers.
La surface d'exposition plus importante de Passport comporte davantage de risques. Quel que soit votre choix, délimitez strictement la portée des jetons et définissez des dates d'expiration. Un jeton sans date d'expiration reste valide jusqu'à ce que quelqu'un pense à le révoquer, ce qui rend une fuite très difficile à maîtriser.
Limiter le débit de chaque point de terminaison public
Le middleware « throttle » de Laravel ne tient qu’à une seule ligne de code, et il est facile de l’oublier dans une route API. Sans lui, les attaques par « credential stuffing » et par énumération s’exécutent à la vitesse maximale autorisée par votre serveur.
Limitation du nombre de requêtes par utilisateur et par adresse IP, avec des restrictions plus strictes concernant la connexion, la réinitialisation du mot de passe et toute opération impliquant l'envoi d'e-mails ou de SMS. Renvoyer un code d'erreur 429 plutôt que de générer une erreur silencieuse.
Renforcez la couche située sous votre application
La sécurité d'une API dépend entièrement de celle du serveur qui l'héberge. Imposez l'utilisation du protocole TLS, désactivez l'affichage des répertoires et appliquez les correctifs au système d'exploitation et à l'environnement d'exécution PHP indépendamment du cycle de publication de Laravel.
La sécurité au niveau de l'application ne résiste pas à la compromission d'un serveur. Quelles que soient les modifications que vous apportez au code source de Laravel, l'infrastructure sous-jacente doit être renforcée et mise à jour selon ses propres critères.
Remarque : Laravel 13 a formalisé la protection contre la falsification des requêtes sous le nom de PreventRequestForgery, qui ajoute une vérification de l'origine dans l'en-tête Sec-Fetch-Site du navigateur, en plus de la validation habituelle du jeton. Une requête provenant de la même origine est autorisée sans jeton, et toute requête qui ne passe pas la vérification d’origine est alors soumise à la validation du jeton. La documentation de Laravel précise que cet en-tête n’est présent que sur HTTPS ; le protocole HTTP simple repose donc toujours entièrement sur le jeton. Renseignez-vous sur ce que le middleware vérifie réellement avant d’exempter quoi que ce soit de ce contrôle.
Fournisseurs et solutions de sécurité Laravel
Assistance à vie TuxCare
ELS intègre des correctifs de sécurité dans les versions de Laravel que l'équipe principale ne maintient plus, via Composer, ce qui permet de ne pas modifier le flux de gestion des dépendances. TuxCare prend également en charge les environnements d’exécution PHP en fin de vie , ce qui est important lorsqu’une ancienne application Laravel repose également sur une version de PHP pour laquelle le développeur en amont a cessé de fournir des correctifs.
ELS ne remplace pas une mise à niveau à terme. Il s'agit d'un support de sécurité à long terme pour les branches dont les versions en amont ne bénéficient plus de correctifs ; vous continuez ainsi à recevoir les correctifs CVE pour une branche en fin de vie (EOL) et pouvez planifier la migration selon votre propre calendrier, plutôt que selon celui de quelqu'un d'autre.
Nous prenons actuellement en charge les versions suivantes de Laravel : 5.4.36, 5.5.50, 5.6.40, 5.7.29, 5.8.38, 6.20.45, 7.30.7, 8.12.0, 8.12.1, 8.12.2, 8.12.3, 8.83.29, 9.52.21, 10, 11, 12.58.0.
Analyse des dépendances
Commencez par composer audit, car il est gratuit et déjà installé. Il analyse vos paquets installés ; les dépendances transitives sont donc également prises en compte, et composer audit –locked vérifie le fichier de verrouillage à la place lorsque le répertoire « vendor » n'est pas présent. Snyk, GitHub Dependabot et Aikido ajoutent à cela une surveillance continue, des alertes et des pull requests de mise à jour automatisées, ce qui est utile lorsque personne ne surveille de près l'intégration continue (CI). Pour une petite équipe, Dependabot constitue une base de référence raisonnable. Ce qu'aucun d'entre eux ne résout, ce sont les paquets en fin de vie (EOL), pour lesquels il n'existe tout simplement pas de version fixe vers laquelle effectuer la mise à jour.
Protection et surveillance en temps réel
Un pare-feu d’application web permet simplement de gagner du temps entre la divulgation d’une faille et la publication d’un correctif, rien de plus. Cloudflare, AWS WAF et ModSecurity, associés à un ensemble de règles régulièrement mis à jour tel que l’OWASP Core Rule Set, peuvent bloquer de nombreuses attaques courantes par injection et de nombreuses charges utiles XSS avant qu’elles n’atteignent PHP, même si la couverture dépend entièrement des règles que vous activez. Associez le pare-feu à une surveillance des journaux afin qu’une tentative d’exploitation se distingue d’une simple requête erronée.
Sécuriser les applications Laravel avec TuxCare
C’est justement pour maintenir une application Laravel dans sa fenêtre de support que les équipes prennent du retard. Les mises à jour majeures entraînent des changements incompatibles, et elles entrent en concurrence avec la livraison de fonctionnalités au cours du même sprint. Si votre version a dépassé sa date de fin de vie (EOL) et qu’aucune migration n’est prévue ce trimestre, le support à cycle de vie illimité de TuxCare pour Laravel garantit que votre application reste à jour jusqu’à ce que vous soyez prêt à passer à la version suivante.
