doganddev
Accueil Blog Boutique

Erreurs de sécurité courantes dans les apps Laravel (et comment les corriger)

DOG&DEV · 25/01/2025

Virtualisation VPN Sécurité
Erreurs de sécurité courantes dans les apps Laravel (et comment les corriger)

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_KEY dans les repos).

Ressources


Cet article s’inscrit dans notre série de guides technique et développement web. Pour un serveur ou une application sur-mesure, contact.

Commentaires (0)

Laisser un commentaire