Erreurs de sécurité courantes dans les apps Laravel (et comment les corriger)
DOG&DEV · 25/01/2025
Erreurs de sécurité courantes dans les apps Laravel (et comment les corriger)
Laravel fournit de bons réflexes de sécurité par défaut, mais des contournements ou des oublis (CSRF, SQL, XSS, mass assignment, APP_DEBUG, uploads, .env) peuvent créer des brèches. Ce guide passe en revue les erreurs les plus fréquentes et la manière correcte de les éviter.
Prérequis
- Application Laravel (traditionnel ou API)
- Connaissances de base en formulaires, Eloquent et Blade
1. CSRF : ne pas désactiver ni oublier le token
Une requête CSRF pousse un utilisateur connecté à exécuter une action sans le vouloir (changement d’email, suppression, etc.). Laravel protège les formulaires via un token vérifié par le middleware VerifyCsrfToken.
À éviter : formulaire sans @csrf :
<form method="POST" action="/profile/update">
<input type="text" name="name" />
<button type="submit">Enregistrer</button>
</form>
Correct :
<form method="POST" action="/profile/update">
@csrf
<input type="text" name="name" />
<button type="submit">Enregistrer</button>
</form>
AJAX / API web : envoyer le token dans l’en-tête X-CSRF-TOKEN (récupéré depuis la balise meta name="csrf-token"). Pour les APIs pures (JSON, tokens stateless), exclure les routes concernées dans VerifyCsrfToken — mais dans ce cas l’auth (Sanctum, JWT, etc.) et le rate limiting sont indispensables.
2. Injection SQL : requêtes brutes et paramètres
Laravel (Eloquent, Query Builder) échappe les paramètres quand on évite la concaténation. Le risque apparaît avec DB::select / raw() et des entrées utilisateur non liées.
À éviter :
$users = DB::select("SELECT * FROM users WHERE email = '$email'");
Correct : Eloquent ou binding :
$user = User::where('email', $email)->first();
// Ou en raw
$users = DB::select('SELECT * FROM users WHERE email = ?', [$email]);
3. XSS : échapper les sorties Blade
Si du contenu non fiable est affiché sans échappement, un attaquant peut injecter du JavaScript. Blade échappe par défaut avec {{ }}.
À éviter : {!! $message !!} avec du contenu utilisateur non sanitized.
Correct : {{ $message }}.
Si vous devez autoriser du HTML (éditeur riche), sanitizer avant stockage et restreindre les balises :
$clean = strip_tags($input, '<p><strong><em><ul><li>');
4. Mass assignment : $fillable ou $guarded
Avec $guarded = [], tous les attributs sont assignables. Un attaquant peut envoyer is_admin, role, balance, etc.
À éviter :
protected $guarded = [];
Correct : $fillable ou $guarded ciblé, et en contrôleur ne mettre à jour que les champs prévus :
protected $fillable = ['name', 'email'];
// Contrôleur
$user->update($request->only(['name', 'email']));
5. APP_DEBUG en production
Avec APP_DEBUG=true en prod, les pages d’erreur exposent stack traces, chemins, requêtes, parfois des variables d’environnement. C’est une fuite d’information majeure.
Correct en production :
APP_ENV=production
APP_DEBUG=false
6. Upload de fichiers
Accepter n’importe quel fichier, sans validation de type, taille ou nom, ouvre la porte à des exécutables, des scripts, ou du contournement de limites.
À éviter :
$request->file('file')->store('uploads');
Correct : validation stricte, stockage hors public si possible, noms renommés (uuid, hash) :
$request->validate([
'file' => 'required|file|mimes:jpg,jpeg,png,pdf|max:2048',
]);
$path = $request->file('file')->store('documents', 'private');
7. .env et APP_KEY
Si le .env ou l’APP_KEY sont exposés (repo, backup, lien), un attaquant peut forger des cookies, décrypter des sessions ou des données chiffrées.
Règles : ne jamais commiter .env ; utiliser .env.example ; restreindre les accès serveur ; en cas de fuite, régénérer APP_KEY (php artisan key:generate) et invalider les sessions.
Dépannage
| Symptôme | Piste | Correctif |
|---|---|---|
| 419 sur formulaire POST | Token CSRF absent ou expiré | @csrf ; rafraîchir la page ; vérifier les exclusions VerifyCsrfToken |
| Données modifiées sans le vouloir | Mass assignment | $fillable / $guarded et $request->only([...]) |
| Stack trace visible en prod | APP_DEBUG=true |
APP_DEBUG=false et APP_ENV=production |
Bonnes pratiques
- FormRequest pour toute entrée ; Policy / Gate pour l’autorisation.
- Rate limiting sur login, inscription et API.
- Audit : journaux, détection de fuites (ex. GitGuardian pour
APP_KEYdans les repos).
Ressources
- Tech Verse Daily – Common Security Mistakes in Laravel Apps
- Documentation Laravel – Validation
- Documentation Laravel – Authorization
Cet article s’inscrit dans notre série de guides technique et développement web. Pour un serveur ou une application sur-mesure, contact.