Sécurité dans les applications Laravel : vulnérabilités courantes et comment les éviter

La sécurité n'est pas une fonctionnalité. C'est ce qui reste quand tout le reste échoue.

Chez Nebula, la sécurité fait partie de chaque projet dès le premier jour. Pas parce que nous sommes paranoïaques, mais parce que les attaques réelles n'attendent pas que quelqu'un ait le temps de « penser à la sécurité plus tard ».

Laravel dispose de mécanismes de défense solides. Mais ils ne sont pas automatiques : il faut les connaître, les activer et les utiliser correctement. Voici les vulnérabilités les plus courantes que nous trouvons lors d'audits réels et comment les résoudre.

Les vulnérabilités les plus fréquentes dans les applications Laravel

1. Injection SQL

Laravel dispose d'un ORM (Eloquent) et d'un query builder qui échappent automatiquement les paramètres. Le problème apparaît quand quelqu'un utilise des requêtes SQL brutes avec des variables utilisateur interpolées directement.

Le scénario typique : un développeur a besoin d'une requête qu'il ne peut pas facilement faire avec l'ORM et écrit du SQL brut en concaténant des variables de la requête directement dans la chaîne. C'est le chemin direct vers une attaque par injection SQL.

La solution : si vous avez besoin de requêtes brutes, Laravel permet d'utiliser des paramètres de liaison - des placeholders que le framework échappe automatiquement. Il ne faut jamais concaténer des variables utilisateur dans du SQL directement.

L'ORM de Laravel existe précisément pour éviter ce problème. Si vous l'évitez, demandez-vous pourquoi.

2. Cross-Site Scripting (XSS)

Blade, le moteur de templates de Laravel, échappe automatiquement les variables quand vous utilisez la syntaxe standard. Le problème survient quand on utilise la syntaxe « HTML sans échappement » pour afficher du contenu dynamique provenant de l'utilisateur.

La règle sans exception : ne jamais rendre du HTML généré par l'utilisateur sans le sanitiser d'abord. Laravel a des helpers pour ça. Si vous devez afficher du HTML utilisateur pour une raison légitime, sanitisez avec une bibliothèque dédiée avant de rendre.

3. Mass Assignment

Eloquent permet de créer ou mettre à jour des enregistrements en passant directement les données de la requête. Si vous ne définissez pas explicitement quels champs sont assignables en masse (la propriété fillable du modèle), un attaquant peut inclure des champs supplémentaires dans la requête - comme role, is_admin ou balance - et les modifier.

Tous les modèles doivent avoir explicitement défini quels champs peuvent être modifiés de l'extérieur. Sans exceptions, sans modèle avec une liste vide qui « se complète plus tard ».

4. Authentification faible

Les problèmes les plus courants que nous trouvons lors d'audits :

Tokens d'API stockés en texte clair dans la base de données (ils doivent être stockés sous forme de hachages)

Absence de rate limiting sur les endpoints de connexion (permet des attaques par force brute illimitées)

Tokens de réinitialisation de mot de passe qui n'expirent pas ou qui peuvent être utilisés plusieurs fois

Sessions qui ne sont pas invalidées lors du changement de mot de passe ou quand un compte est marqué comme compromis

Laravel Sanctum et Passport fournissent une authentification sécurisée, mais ils doivent être configurés correctement. Les valeurs par défaut ne sont pas toujours suffisantes pour les applications de production.

5. Exposition d'informations sensibles

Erreurs de configuration qui exposent des informations qui ne devraient pas être publiques :

Mode debug activé en production : expose des stack traces complets avec les chemins du serveur, les variables d'environnement et les requêtes SQL. Toute erreur en production peut révéler des informations sensibles sur l'infrastructure.

Fichier .env accessible : une mauvaise configuration du serveur web peut exposer le fichier de variables d'environnement avec les identifiants de base de données, les clés API et les secrets.

Logs avec données sensibles : des logs qui enregistrent des mots de passe en texte clair, des tokens complets ou des numéros de carte - souvent par erreur, dans les logs de debug.

Ce que nous faisons dans chaque projet

Revue des points d'entrée

Avant tout changement, nous cartographions tous les points d'entrée du système : formulaires, endpoints API, paramètres d'URL, uploads de fichiers, intégrations tierces. Chacun est une surface d'attaque potentielle.

HTTPS et headers de sécurité

Tout en HTTPS, sans exception. Nous configurons également les headers HTTP que beaucoup d'applications ignorent : Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security. Ces headers préviennent des catégories entières d'attaques avec une seule ligne de configuration.

Validation à toutes les frontières du système

Toute entrée utilisateur est validée avec les Form Requests de Laravel avant d'être traitée. Les fichiers uploadés sont validés par type MIME réel (pas seulement l'extension), taille maximale, et stockés en dehors du répertoire public. Les données qui seront affichées en HTML sont sanitisées.

Rate limiting sur les endpoints sensibles

Connexion, inscription, réinitialisation de mot de passe et toute API publique ont un rate limiting configuré. Ça n'élimine pas les attaques sophistiquées, mais ça élimine 90% du bruit automatisé qui touche tout système en production.

Surveillance et alertes

Les événements de sécurité sont enregistrés : tentatives de connexion échouées répétées, accès depuis des IPs inhabituelles, erreurs critiques. Si vous ne savez pas que quelqu'un teste votre système, vous ne pouvez pas vous défendre.

Quand un audit de sécurité a-t-il du sens ?

Avant le lancement d'un nouveau système qui gère des données sensibles ou de l'argent

Après l'ajout d'un module de paiement ou d'intégrations tierces

Quand le système va passer à l'échelle et que plus de personnes vont y accéder

Quand le code a plusieurs années et a été touché par plusieurs développeurs sans processus de revue cohérent

Quand il y a eu un incident de sécurité - ou presque

Sécurité sans excuses

Les vulnérabilités que nous décrivons ne sont pas théoriques. Ce sont celles que nous trouvons dans des applications réelles d'entreprises réelles. Et la plupart ont une solution directe si elles sont identifiées à temps.

Si vous avez un système Laravel en production et que vous n'êtes pas certain qu'il est bien protégé, c'est le moment de le découvrir.

Nous réalisons des audits de sécurité avec un rapport concret : ce qui ne va pas, quel risque cela représente et comment le corriger. Sans alarmisme inutile, sans vendre des solutions qui ne sont pas nécessaires.

Planifiez un audit de sécurité.