Test d'intrusion Laravel : Mode Debug, Désérialisation et Sécurité des API
Laravel est le framework PHP le plus populaire au monde, utilisé par des millions d'applications en production. Sa richesse fonctionnelle — Eloquent ORM, queues, événements, Artisan CLI — introduit une surface d'attaque complexe que les scans automatisés génériques ne couvrent pas. CVE-2024-29291 a démontré que le mode debug activé en production expose des informations système critiques permettant d'accélérer toute attaque ciblée. CVE-2024-52301 a montré que des variables d'environnement sensibles pouvaient être exposées via des endpoints dédiés. Matproof examine votre application Laravel pour toutes les vulnérabilités connues et les erreurs de configuration propres à ce framework.
Pourquoi les applications Laravel nécessitent des tests de sécurité spécialisés
Laravel offre des abstractions puissantes qui peuvent donner un sentiment de sécurité trompeur. L'Eloquent ORM protège contre les injections SQL classiques mais ne prévient pas les requêtes brutes mal construites, le mass-assignment non contrôlé ou les relations trop permissives. Le système de sérialisation PHP sous-jacent, utilisé par les sessions, les queues et le cache, est une cible historique d'attaques par désérialisation. Le fichier .env contient des secrets critiques (clés APP_KEY, identifiants de base de données, tokens d'API) dont l'exposition compromet immédiatement l'ensemble de l'application. La combinaison de ces caractéristiques avec un écosystème de packages Composer vaste et des configurations par défaut parfois permissives fait de Laravel une cible de choix pour les attaquants expérimentés.
- CVE-2024-29291 (mode debug Laravel en production) : lorsque APP_DEBUG=true est activé en production, les pages d'erreur Laravel exposent des stack traces complètes incluant les variables d'environnement, les chemins de fichiers système, les identifiants de base de données et les configurations d'infrastructure. Un attaquant obtient en quelques secondes une cartographie précise de l'environnement cible, accélérant considérablement tout plan d'attaque.
- CVE-2024-52301 (exposition des variables d'environnement) : cette vulnérabilité dans certaines versions de Laravel et packages associés permettait l'exposition non autorisée de variables d'environnement via des endpoints de diagnostic ou des configurations incorrectes. Les clés APP_KEY, tokens de base de données et secrets d'API figuraient parmi les données exposées.
- CVE-2018-15133 (désérialisation PHP non sécurisée dans Laravel) : la valeur APP_KEY compromise permet à un attaquant de forger des cookies de session malveillants exploitant la désérialisation PHP pour obtenir une exécution de code arbitraire (RCE). Bien que datant de 2018, ce vecteur reste pertinent pour les applications utilisant des versions non patchées ou des configurations de session basées sur des cookies non chiffrés.
- Mass-assignment via l'Eloquent ORM : l'absence de définition explicite des propriétés fillable ou guarded dans les modèles Eloquent permet à un attaquant de modifier des champs arbitraires lors des opérations de création ou de mise à jour — y compris des champs sensibles comme is_admin, role ou email_verified_at.
- Injection SQL dans les requêtes brutes : l'utilisation de DB::select(), DB::statement() ou whereRaw() avec des données utilisateur non paramétrées crée des vulnérabilités d'injection SQL que l'ORM ne peut pas prévenir automatiquement. Les applications complexes mélangent souvent requêtes Eloquent et requêtes brutes.
- Exposition des fichiers .env et routes de diagnostic : les configurations serveur incorrectes ou les déploiements sans préparation adéquate laissent parfois le fichier .env accessible directement. De même, les routes /telescope, /_debugbar ou /horizon peuvent être accessibles sans authentification en production.
- Vulnérabilités dans les packages Composer tiers : l'écosystème Packagist compte des milliers de packages Laravel ; les dépendances abandonnées ou non maintenues peuvent contenir des CVE non patchés. Un audit des dépendances révèle fréquemment des packages critiques en fin de vie dans les applications Laravel établies.
Ce qui est examiné lors d'un test d'intrusion Laravel
- Configuration de l'environnement et gestion des secrets : vérification de APP_DEBUG, APP_ENV, exposition du fichier .env, accessibilité des routes de diagnostic (Telescope, Debugbar, Horizon) et configuration des permissions sur les fichiers sensibles.
- Sécurité de l'authentification et des sessions : analyse des mécanismes d'authentification (Laravel Sanctum, Passport, Breeze, Fortify), des cookies de session (driver, chiffrement, flags HttpOnly/Secure/SameSite), de la gestion des tokens et de la protection contre la fixation de session.
- Mass-assignment et sécurité des modèles Eloquent : audit de tous les modèles pour les propriétés fillable/guarded, test des endpoints de création et mise à jour pour l'injection de champs non autorisés, vérification des relations accessibles via les API.
- Injection SQL et requêtes brutes : test systématique de toutes les constructions DB::, whereRaw(), selectRaw() et orderByRaw() pour les entrées utilisateur non paramétrées ; analyse des requêtes complexes avec jointures pour les injections de second ordre.
- Sécurité des queues et de la désérialisation : évaluation du risque CVE-2018-15133 basé sur la solidité de l'APP_KEY ; analyse des jobs en queue pour les vulnérabilités d'injection de commandes ou d'accès non autorisé aux données ; test de la sécurité du driver de queue (Redis, database, SQS).
- Contrôle d'accès et politiques d'autorisation : audit des politiques Laravel (Policies), des Gates et des middlewares d'autorisation ; test pour IDOR (Insecure Direct Object Reference) sur les ressources scopées par utilisateur ; vérification de l'isolation des données multi-tenant.
- Sécurité des API REST (Laravel API Resources) : authentification des endpoints, rate-limiting, validation des entrées, format de réponse pour la divulgation d'informations, gestion des erreurs exposant des informations internes.
- Upload de fichiers et validation : test des restrictions de type MIME, des vérifications de contenu réel (magic bytes), de la prévention de path traversal lors des uploads, et de l'accès public vs privé aux fichiers stockés via Laravel Storage.
- Sécurité CSRF et validation des formulaires : vérification de la protection CSRF sur tous les formulaires et endpoints mutants, validation des Form Requests, protection contre les attaques de soumission de formulaire inter-origines.
- Audit des dépendances Composer : scan de toutes les dépendances (directes et transitives) contre NVD et la base de données d'avis de sécurité Packagist ; identification des packages abandonnés avec des vulnérabilités connues.
Exemple de finding
Mode debug Laravel actif en production — exposition des secrets d'environnement (CVE-2024-29291)
L'application Laravel en production a été déployée avec APP_DEBUG=true dans le fichier .env. Lors du déclenchement d'une exception non gérée sur l'endpoint /api/v1/users/{id} (via un paramètre id=999999 inexistant), la réponse d'erreur Ignition exposait : la valeur complète de APP_KEY (base64:xxx), l'URL de connexion à la base de données avec identifiants, le chemin absolu du répertoire applicatif, les variables d'environnement AWS_SECRET_ACCESS_KEY et STRIPE_SECRET. Ces informations permettent la compromission complète de l'application via CVE-2018-15133 (APP_KEY compromise) et un accès direct à la base de données et aux services cloud.
Correction : Définir immédiatement APP_DEBUG=false et APP_ENV=production dans le fichier .env de production. Regénérer l'APP_KEY (php artisan key:generate) et faire pivoter tous les secrets exposés (base de données, AWS, Stripe). Configurer un handler d'exceptions personnalisé retournant des réponses d'erreur génériques sans informations internes. Implémenter une politique de révision de configuration pré-déploiement incluant la vérification de APP_DEBUG. Référence : Laravel Security Advisory, OWASP A05:2021 Security Misconfiguration.
Référence : CVE-2024-29291 · CVE-2018-15133 (RCE via APP_KEY compromise) · OWASP A05:2021 Security Misconfiguration · CWE-209 Generation of Error Message Containing Sensitive Information
Pentest Laravel : comparaison des options
| — | Scan gratuit | Matproof Sentinel | Consultance classique |
|---|---|---|---|
| Moteur de scan automatisé | ✓ (aperçu 3 min) | ✓ Scan complet | ✗ Manuel uniquement |
| Couverture OWASP Top 10 | Partielle | ✓ Complète | ✓ Complète |
| Preuve d'exploitation | ✗ | ✓ Par finding | ✓ Par finding |
| Mapping réglementaire (DORA/NIS2/ISO 27001) | ✗ | ✓ Automatisé | ✓ Manuel |
| Rapport PDF prêt pour l'audit | ✗ | ✓ Instantané | ✓ Livraison 2–4 semaines |
| Scans continus / récurrents | ✗ | ✓ Par déploiement | ✗ Engagement annuel |
| Délai avant premier résultat | ~3 min | ~30 min scan complet | 2–4 semaines |
| Prix | €0 | À partir de €149 | €8 000–€25 000 |
| Revue de code source (SAST) | ✗ | ✓ Plan Growth | ✓ Périmètre défini |
| Tests API (REST/GraphQL) | ✗ | ✓ Automatisé | ✓ Manuel |
Offres de pentest Laravel
- 1 scan pentest complet
- Résultats priorisés par IA avec CVSS 3.1
- Proof-of-exploit pour chaque finding
- Rapport PDF (prêt pour l'audit)
- Mapping réglementaire (DORA, NIS2, ISO 27001)
- Scans illimités (jusqu'à 3 domaines)
- Surveillance continue
- Intégration CI/CD (GitHub, GitLab)
- Tous les mappings réglementaires
- Support prioritaire
- Scans + domaines illimités
- Tests authentifiés / White-Box
- Tests d'API et d'infrastructure cloud
- Account manager sécurité dédié
- SLA réponse 24h
Questions fréquentes sur le test d'intrusion Laravel
Que révèle exactement le mode debug Laravel actif en production et pourquoi est-ce critique ?
Quand APP_DEBUG=true est activé en production, toute exception non gérée provoque l'affichage d'une page d'erreur Ignition (ou Whoops) exposant : le stack trace complet avec le code source environnant, toutes les variables d'environnement chargées (y compris APP_KEY, identifiants de base de données, tokens d'API tiers), les chemins absolus du système de fichiers et la configuration de l'infrastructure. Avec l'APP_KEY, un attaquant peut forger des cookies de session malveillants exploitant CVE-2018-15133 pour une exécution de code arbitraire. C'est l'une des misconfiguration les plus graves en Laravel.
Comment fonctionne l'attaque par désérialisation CVE-2018-15133 dans Laravel et les applications récentes sont-elles encore vulnérables ?
CVE-2018-15133 exploite la désérialisation PHP dans les sessions Laravel lorsque le driver de session est configuré sur « cookie ». Si l'APP_KEY est compromise (via le mode debug ou une autre fuite), un attaquant peut créer un cookie de session contenant un payload de désérialisation PHP malveillant signé avec la clé connue. À la désérialisation côté serveur, le payload s'exécute avec les privilèges de l'application web (RCE). Les versions récentes de Laravel utilisant le driver de session « database » ou « file » (par défaut) ne sont pas directement vulnérables à ce vecteur spécifique, mais toute compromission de l'APP_KEY reste critique pour d'autres raisons (forgerie de tokens, déchiffrement des données chiffrées).
Comment prévenir le mass-assignment dans Laravel et comment Matproof le teste-t-il ?
Pour prévenir le mass-assignment : définir explicitement $fillable avec la liste des champs autorisés dans chaque modèle Eloquent (approche liste blanche recommandée) plutôt que $guarded = []. Ne jamais utiliser $guarded = [] en production. Lors du pentest, Matproof envoie des requêtes POST/PUT/PATCH à tous les endpoints d'écriture avec des champs supplémentaires non documentés (is_admin, role, verified, plan_id) et vérifie si ces champs sont persistés en base de données. Les Form Requests avec validation stricte constituent également une couche de protection complémentaire.
Les routes /telescope et /horizon de Laravel sont-elles dangereuses en production ?
Oui — Laravel Telescope (monitoring de debug) et Horizon (monitoring des queues Redis) exposent des informations extrêmement sensibles : toutes les requêtes HTTP avec leurs paramètres et réponses, les queries SQL exécutées avec leurs valeurs, les jobs de queue avec leurs payloads, les logs d'exception et les variables de configuration. Sans authentification en production, ces interfaces constituent une fuite de données massive. Recommandation : désinstaller Telescope en production ou le protéger avec une Gate autorisant uniquement les administrateurs internes via IP allowlist.
Quelle est la sécurité de Laravel Sanctum pour les API et qu'est-ce qui est testé ?
Laravel Sanctum est généralement bien conçu pour son cas d'usage (SPA auth + tokens API simples). Lors du pentest, nous vérifions : la configuration des tokens (expiration, révocation, portées/scopes), la protection CSRF pour les SPAs (cookies vs Bearer tokens), les risques de fuite de tokens dans les logs ou réponses d'erreur, la gestion de la révocation des tokens lors de la déconnexion, les limites de taux sur les endpoints d'authentification et la résistance aux attaques par force brute.
Comment sécuriser les uploads de fichiers dans Laravel et quels vecteurs d'attaque existent ?
Les vecteurs d'attaque sur les uploads Laravel incluent : l'upload de fichiers PHP déguisés en images (contournement de la validation MIME basée sur l'extension), le path traversal si le nom de fichier utilisateur est utilisé directement, l'accès public aux fichiers uploadés devant rester privés, et l'exécution de code si le dossier d'upload est accessible depuis le web. Contre-mesures : toujours valider le contenu réel (mimeTypes avec php-fileinfo), générer des noms de fichiers aléatoires avec Storage::putFile(), stocker les fichiers sensibles dans le disque privé (storage/app/) et servir via des URL signées temporaires avec Storage::temporaryUrl().
Quelle fréquence de pentest est recommandée pour une application Laravel en production ?
Recommandation : pentest complet annuel pour les applications Laravel gérant des données utilisateurs ou des transactions financières, plus un test ciblé après chaque mise à jour majeure de Laravel (ex. passage à Laravel 11), après l'ajout de fonctionnalités sensibles (paiements, upload, authentification) ou après un incident de sécurité. Matproof Sentinel offre une surveillance continue qui détecte les nouvelles vulnérabilités dans les dépendances Composer entre les pentests complets.
Laravel est-il plus sécurisé que Symfony ou d'autres frameworks PHP ?
Laravel et Symfony offrent tous deux de solides protections natives contre les vulnérabilités courantes (injection SQL via l'ORM, CSRF, XSS via Blade). Laravel a l'avantage d'une grande communauté et de mises à jour de sécurité régulières. Cependant, la sécurité d'une application dépend principalement de la façon dont le framework est utilisé : le mass-assignment, les requêtes brutes et les misconfiguration d'environnement sont des erreurs de développeur, pas des failles du framework. Un pentest spécialisé Laravel examine à la fois la configuration du framework et les erreurs d'implémentation spécifiques à l'application.
Approfondir — articles de blog associés
Démarrez votre test d'intrusion Laravel maintenant
Déterminez en quelques minutes si votre application Laravel expose le mode debug, des variables d'environnement sensibles ou des vulnérabilités de désérialisation. Rapport audit-ready en français, aucune installation requise.
Démarrer le pentest Laravel