Checklist sécurité Laravel : 17 pistes pour protéger votre application

Cette checklist regroupe 17 axes de sécurisation pour une application Laravel : protection CSRF, validation, autorisation, rate limiting, gestion de l’APP_KEY et du .env, dépendances, headers, uploads, logs et erreurs. Elle complète les bonnes pratiques du framework et aide à limiter les fuites, les injections et les abus.

Prérequis

• Application Laravel (web et/ou API)
• Accès à la config, aux middlewares et au déploiement

1. CSRF

• Tous les formulaires POST/PUT/PATCH/DELETE (web) incluent @csrf ou l’en-tête X-CSRF-TOKEN.
• Les routes exclues de VerifyCsrfToken sont strictement limitées (API stateless, webhooks) et protégées par un autre mécanisme (token, signature).

2. Validation

• FormRequest ou $request->validate() sur toute entrée utilisateur (formulaires, query, JSON).
• Règles strictes : exists, in, mimes, max ; pas de nullable ou de champs ouverts sans raison.

3. Autorisation

• Gates ou Policies sur les actions sensibles (création, modification, suppression, accès admin).
• $this->authorize() (ou équivalent) dans les contrôleurs ; pas de simple if (auth()->user()->is_admin) oublié dans un coin.

4. Mass assignment

• $fillable ou $guarded défini sur tous les modèles ; jamais $guarded = [] sans audit.
• En contrôleur : $request->only([...]) ou $request->validated() pour restreindre les champs mis à jour.

5. Injection SQL

• Aucune concaténation de variables utilisateur dans du raw SQL ; utiliser Eloquent, Query Builder ou paramètres liés (?, :name).

6. XSS

• {{ }} (échappement Blade) par défaut ; {!! !!} uniquement pour du HTML déjà sanitisé et contrôlé.
• Si éditeur riche : sanitization avant stockage et politique de balises restreinte.

7. APP_DEBUG et APP_ENV

• APP_DEBUG=false et APP_ENV=production en production.
• Vérification via config('app.debug') ou .env sur le serveur (pas de override accidentel).

8. APP_KEY et .env

• .env absent du dépôt Git ; .env.example sans valeurs secrètes.
• APP_KEY unique par environnement ; rotation si fuite ou compromission.
• Utilisation d’outils (ex. GitGuardian) pour détecter des APP_KEY ou secrets dans l’historique Git.

9. Mots de passe et hachage

• Hash::make() / bcrypt (ou argon2 selon la config) pour les mots de passe ; jamais de stockage en clair.
• Politique de complexité (longueur, caractères) et réinitialisation sécurisée (token, expiration).

10. Sessions

• Driver database ou redis en prod (éviter file sur plusieurs instances sans partage).
• SESSION_SECURE_COOKIE et SESSION_SAME_SITE cohérents avec HTTPS et le domaine.
• Invalidation à la déconnexion et timeout adapté.

11. Rate limiting

• Throttle sur login, inscription, réinitialisation de mot de passe, API.
• Limites APIs publiques (par IP, par token) pour éviter abus et déni de service.

12. Headers de sécurité

• HSTS, X-Content-Type-Options, X-Frame-Options, CSP (Content-Security-Policy) selon le besoin ; via middleware ou serveur web.

13. Upload de fichiers

• Validation : mimes, max, image (si pertinent) ; refus des exécutables et noms renommés (uuid, hash).
• Stockage hors public/ pour les fichiers sensibles ; accès via contrôleur authentifié et autorisé.

14. Dépendances

• composer update et composer audit réguliers ; correction des CVE connues.
• npm audit (ou équivalent) pour les paquets front si utilisés dans le build.

15. Logs et erreurs

• Aucune donnée sensible (mots de passe, tokens, PII) dans les logs.
• En prod : ni stack trace, ni dd() / dump() ; gestion des exceptions et reporting (Sentry, etc.) maîtrisée.

16. CORS (APIs)

• Configuration CORS restrictive : origines, méthodes et en-têtes explicitement autorisés ; pas de * en prod si des credentials sont envoyés.

17. Infra et déploiement

• HTTPS obligatoire ; redirection HTTP → HTTPS.
• Permissions des dossiers (storage, bootstrap/cache) et utilisateur d’exécution (pas root).
• Sauvegardes de la BDD et des fichiers ; restauration testée.
• Secrets et .env gérés via variables d’environnement ou secret manager, pas en clair dans le code ou les artifacts.

Dépannage

• Fuite d’APP_KEY : régénérer avec php artisan key:generate ; invalider les sessions ; vérifier l’historique Git et les backups.
• Rate limit trop strict : ajuster throttle dans RouteServiceProvider ou les middlewares ; distinguer web, API, et routes critiques.

Bonnes pratiques

• Réviser cette checklist à chaque nouvelle fonctionnalité sensible et en pré-production.
• Automatiser quand c’est possible : PHPStan/Psalm, composer audit, scripts de déploiement (vérif APP_DEBUG, APP_ENV).

Ressources

• Developer Awam – Laravel Security Checklist (Medium)
• Documentation Laravel – Deployment
• GitGuardian – détection de secrets
• OWASP – Top 10

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