Bonnes pratiques de sécurité pour Laravel – Une liste de conseils pour le codage

Dans ce blog, nous décrivons quelques erreurs de sécurité simples et comment les corriger.

1. Ne pas utiliser HTTPS

• Erreur:Servir votre application Laravel via HTTP au lieu de HTTPS la rend vulnérable aux attaques de l'homme du milieu (MITM) où des données sensibles peuvent être interceptées.
• Solution: Utilisez toujours HTTPS dans les environnements de production en configurant des certificats SSL et en forçant HTTPS en ajoutant ceci à ($this->app->environment('production')) { \URL::forceScheme('https'); }

2. Utilisation de clés de chiffrement faibles

• Erreur:Ne pas parvenir à établir une position forte CLÉ_D'APPLICATION dans le .env fichier, qui est crucial pour le cryptage, la sécurité des sessions et le hachage des mots de passe.
• Solution: Définissez une clé d'application forte à l'aide de la commande suivante : bash
  clé php artisan:générer Assurez-vous que cette clé reste secrète et ne soit jamais partagée publiquement.

3. Ne pas valider les données d'entrée

• Erreur: Ignorer la validation des entrées peut exposer votre application à diverses attaques telles que l'injection SQL, les scripts intersites (XSS) et d'autres vulnérabilités.
• Solution:Utilisez la validation intégrée de Laravel pour vous assurer que toutes les données d'entrée sont nettoyées et respectent le format attendu.php
  $request->validate([ 'email' => 'requis|email', 'mot de passe' => 'requis|min:8', ]);

4. Stockage de données sensibles dans la base de code

• Erreur:Le codage en dur de données sensibles telles que les clés API, les informations d'identification de base de données ou les jetons privés directement dans la base de code peut entraîner des failles de sécurité si le code est partagé ou exposé.
• Solution: Stocker des informations sensibles dans des variables d'environnement (.env) et utilisez le système de configuration de Laravel pour les charger. Ne validez jamais le .env fichier vers le contrôle de version.

5. Autorisations de fichiers incorrectes

• Erreur: Autoriser les autorisations d'écriture sur des fichiers sensibles, tels que .env fichier, peut permettre à des utilisateurs non autorisés d'accéder aux données de configuration.
• Solution: Définissez les autorisations de fichiers appropriées pour votre projet Laravel. En général, vous voulez des répertoires comme stockage et démarrage/cache être accessible en écriture par le serveur Web, mais les autres fichiers ne doivent pas être accessibles en écriture.

6. Ne pas échapper au contenu généré par les utilisateurs

• Erreur:Le fait de ne pas échapper aux données générées par l’utilisateur avant de les afficher sur la page peut conduire à des attaques XSS.
• Solution:Utilisez le moteur de création de modèles intégré de Laravel, Blade, qui échappe automatiquement la sortie. Si vous devez désactiver l'échappement (ce qui est rare), assurez-vous que le contenu est correctement nettoyé.

{{ $userInput }} // Échappé
{!! $userInput !!} // Sans échappement (Attention)

7. Pas de limitation de l'affectation de masse

• Erreur:Autoriser l'affectation de masse sur les modèles sans contrôler correctement les champs remplissables peut permettre aux attaquants de modifier des champs non prévus.
• Solution:Utilisez le $remplissable ou $ gardé propriétés dans vos modèles Eloquent pour spécifier quels champs peuvent être attribués en masse.php
  protégé $fillable = ['nom', 'email'];

8. Exposer le mode débogage en production

• Erreur: Sortie APP_DEBUG=vrai dans le .env Les fichiers dans les environnements de production peuvent exposer des informations sensibles telles que les traces de pile, les informations d'identification de la base de données et les clés API dans les messages d'erreur.
• Solution: Toujours définir APP_DEBUG=faux en production, et envisagez d'utiliser la journalisation des erreurs pour capturer et stocker en toute sécurité les erreurs sans les révéler publiquement.

9. Gestion non sécurisée du téléchargement de fichiers

• Erreur:Le fait de ne pas valider et de ne pas nettoyer correctement les fichiers téléchargés peut entraîner des téléchargements de fichiers malveillants, qui peuvent exécuter du code côté serveur.
• Solution:Utilisez les règles de validation de téléchargement de fichiers de Laravel pour vérifier le type, la taille et d'autres attributs des fichiers téléchargés.php
  $request->validate([ 'fichier' => 'requis|fichier|mimes:jpg,png,pdf|max:2048', ]);

Stockez les fichiers en dehors du répertoire public et utilisez des méthodes sécurisées pour y accéder.

10. Ne pas mettre en œuvre la limitation de débit

• Erreur:Le fait de ne pas mettre en œuvre la limitation de débit sur les itinéraires sensibles tels que les points de terminaison de connexion ou d'API peut exposer votre application à des attaques par force brute ou par déni de service (DoS).
• Solution:Utilisez le middleware de limitation de débit intégré de Laravel pour protéger votre routes.php
  Route::middleware('throttle:10,1')->group(function () { Route::post('/login', 'AuthController@login'); });

11. Exposition inutile de points finaux sensibles

• Erreur:Laisser des itinéraires sensibles comme /télescope, /horizon, ou /admin accessible au public peut exposer des outils de débogage ou d'administration précieux.
• Solution: Protégez ces routes en limitant l'accès via un middleware ou une liste blanche d'adresses IP. Par exemple, limitez l'accès à Laravel Telescope aux environnements locaux :php
  si (app()->environment('local')) { Télescope::auth(fonction () { renvoie vrai; }); }

12. Laravel et ses dépendances obsolètes

• Erreur:L'exécution de versions obsolètes de Laravel ou de ses dépendances peut laisser des vulnérabilités connues non corrigées.
• Solution: Mettez à jour régulièrement Laravel et ses dépendances en exécutant mise à jour du compositeuret surveillez les avis de sécurité pour les packages que vous utilisez.

13. Ne pas utiliser la protection CSRF

• Erreur:L’absence de mise en œuvre de la protection contre la falsification de requêtes intersites (CSRF) peut permettre aux attaquants d’inciter les utilisateurs à effectuer des actions en leur nom.
• Solution: Laravel inclut la protection CSRF par défaut pour toutes les requêtes POST, PUT, PATCH et DELETE à l'aide de la @csrf directive dans forms.blade
  @csrf Soumettre

14. Ne pas utiliser de hachage de mot de passe sécurisé

• Erreur:Le stockage des mots de passe en texte brut ou l’utilisation d’algorithmes de hachage faibles rend votre application vulnérable si la base de données est compromise.
• Solution: Utilisez toujours Laravel bcrypt (ou argon2 pour une sécurité renforcée) pour le hachage des mots de passe :php
  utilisez Illuminate\Support\Facades\Hash; $hashedPassword = Hash::make($password);

15. Ignorer les journaux et les alertes

• Erreur:Le fait de ne pas surveiller les journaux d’application pour détecter des activités suspectes ou des erreurs peut conduire à des incidents de sécurité manqués.
• Solution: Vérifiez régulièrement les journaux de Laravel (stockage/journaux) et configurez des alertes pour les événements critiques. Vous pouvez intégrer Laravel à des outils de surveillance tiers comme Sentry ou New Relic pour une surveillance en temps réel.

16. Mise à jour avec $request->all()

Un peu similaire au point 7.

Bien que cela semble vraiment pratique, lorsque vous mettez à jour un utilisateur comme ceci :

$user->update($request->all());

Il existe un risque de sécurité. Par exemple, si vous avez une colonne this_is_an_admin=1, un utilisateur peut définir cette variable via la console développeur du navigateur.

Il serait préférable de filtrer uniquement la bonne variable $request avec :

$request->only(['nom', 'newsletter_subscribed']);

Vous avez d'autres questions de sécurité ? Faites-le nous savoir dans les commentaires !