La pratique Laravel sécurité liste de contrôle

Par Andrea Pollastri · Dernière mise à jour : 4 août 2026 · lecture gratuite, pas de paywall

La plupart des applications Laravel ne sont pas piratées par des zero-days intelligents. Ils sont piratés par des fichiers .env exposés, le mode de débogage est laissé activé, PHP non corrigé et un SSH faible. Cette liste de contrôle couvre d'abord le travail ennuyeux et à fort impact (serveur, application, dépendances, secrets et réponse) avec un moyen d'automatiser chaque étape.

Qu'est-ce qui fait réellement pirater les applications Laravel ?

Classés selon la fréquence à laquelle ils apparaissent dans des incidents réels, et non selon leur intérêt :

1. Sortie de débogage exposée. APP_DEBUG=true dans un environnement de fuites de production variables, informations d'identification de la base de données et chemins de fichiers à toute personne déclenchant une erreur.
2. Lisible .env ou .git/. Racines de document mal configurées qui servez les fichiers dotfiles et remettez votre APP_KEY et vos informations d'identification.
3. PHP, framework ou packages non corrigés avec des CVE connus.
4. SSH faible : authentification par mot de passe, connexion root activée, pas de protection par force brute.
5. Téléchargements de fichiers dangereux qui autorisent le contenu exécutable dans les chemins servis sur le Web.
6. Injection dans les trappes de secours : SQL brut sans liaisons, sans échappement {!! !!} Sortie de lame.
7. Panneaux d'administration sans MFA et sans limitation de taux.

L'ennui vaut mieux que l'intelligent : si vous fermez ces sept portes, vous êtes en avance sur la grande majorité de la production PHP déploiements.

Liste de contrôle pour le renforcement du serveur

• SSH : clés uniquement, pas de root.Désactivez l'authentification par mot de passe et la connexion root ; utiliser un utilisateur administrateur dédié. Ajoutez Fail2ban pour bannir les échecs répétés. (Un nouveau Cipi install applique exactement ceci par défaut : connexion root désactivée, accès administrateur par clé uniquement, Fail2ban et UFW activés.)
• Refus par défaut du pare-feu. Seuls 22, 80 et 443 devraient répondre. Bases de données et Valkey/Redis écouter sur localhost - vérifier avec ss -tlnp.
• TLS partout, forcé. Certificats Let's Encrypt gratuits, HTTP redirigé vers HTTPS (cipi ssl install alors cipi ssl force), HSTS activé.
• Patchez selon un calendrier, pas sur la mémoire. Mises à jour de sécurité sans surveillance pour le système d'exploitation ; un mécanisme délibéré pour PHP (Cipi exécute une vérification hebdomadaire des correctifs de sécurité PHP - cipi php upgrade).
• Réduisez les empreintes digitales : expose_php = Off, server_tokens off.
• Isolez les applications les unes des autres. Les utilisateurs du système par application et les pools PHP-FPM limitent l'explosion rayon lorsqu’une application est compromise – Cipi provisionne automatiquement cet isolement par application.
• Retirez les restes : fichiers phpinfo, administrateur, sous-domaines obsolètes pointant vers d'anciens boîtes.

Liste de contrôle pour le renforcement des applications

• APP_ENV=production, APP_DEBUG=false - non négociable.
• Forcer HTTPS au niveau de l'application aussi (proxys de confiance + schéma forcé), donc URL signées et les cookies se comportent.
• Validez le tout avec les demandes de formulaire ; ne faites jamais confiance aux entrées du client, y compris les en-têtes et les noms de fichiers.
• Gardes à affectation massive : explicite $fillable sur chaque modèle.
• Autoriser avec des stratégies sur chaque itinéraire qui touche les données de quelqu'un d'autre ; ajouter Route::can() / middleware, not ad-hoc ifs.
• Limite de taux connexion, enregistrement, réinitialisation du mot de passe et API publiques avec Laravel Limiteur de taux.
• Indicateurs de session et de cookies : secure, http_only, same_site configuré dans config/session.php.
• Restez à l’intérieur des liaisons Eloquent. Si vous devez utiliser whereRaw, passer les liaisons - n'interpolez jamais les entrées dans les chaînes SQL.
• Échapper par défaut. Traiter {!! !!} comme une odeur de code nécessitant une justification et la désinfection.
• Téléchargements de fichiers : valider le type et la taille MIME, stocker à l'extérieur public/ avec noms aléatoires, servis via des URL signées ou un contrôleur.
• En-têtes de sécurité : X-Frame-Options, X-Content-Type-Options, Referrer-Policy et un CSP approprié à votre frontend.

Dépendances et chaîne d'approvisionnement

Votre application est principalement constituée du code d'autres personnes, alors considérez l'hygiène des dépendances comme un contrôle de sécurité de premier ordre :

• Valider les fichiers de verrouillage (composer.lock, package-lock.json) donc la production exécute exactement ce que vous avez testé.
• Courir composer audit en CI à chaque demande d'extraction - la construction échoue lorsque une dépendance a un avis connu. (Le câblage dans un pipeline prend cinq minutes - voir notre Guide CI/CD.)
• Automatiser les PR de mise à jour avec Renovate ou Dependabot ; de petites bosses hebdomadaires battent trimestriellement méga-améliorations.
• Recherchez les erreurs de configuration spécifiques à Laravel. Point de contrôle est un open-source Laravel scanner de sécurité que vous pouvez ajouter à votre chaîne d'outils pour détecter les erreurs au niveau du framework avant qu'elles ne surviennent. navire.
• Scannez également de l’extérieur. Une plateforme comme Hackly fonctionne de manière récurrente analyse les vulnérabilités sur votre surface publique – la vue de l'attaquant sur votre pile, selon un calendrier.

Secrets et protection des données

• .env n'entre jamais dans Git. Distribuez des secrets via vos outils de déploiement, pas le référentiel.
• Utilisateurs de base de données bénéficiant du moindre privilège : un utilisateur par application, non GRANT ALL sur *.*. (Cipi crée une base de données dédiée et un utilisateur par application.)
• Chiffrez la configuration de l’infrastructure au repos. Cipi stocke la configuration de son serveur et de ses applications chiffrées avec AES-256 sur votre VPS — les métadonnées de l'infrastructure ne quittent jamais la machine.
• Portée API jetons (Capacités du Sanctum) et faites pivoter les informations d'identification lorsque les gens partent.
• Anonymisez les données de production avant de les partager. Ne confiez jamais les décharges de production à une zone de préparation ou développeurs externes bruts ; le CipiAgent Le forfait Laravel comprend un anonymiseur de base de données pour exactement ce flux de travail.
• Sauvegardes cryptées hors site - et testez le chemin de restauration (voir le guide de déploiement pour la sauvegarde configuration).

Détection, surveillance et réponse

• Centralisez les exceptions. Un pic de 500 est souvent le premier signe d’une enquête. Google vous donne un self-hosted suivi des exceptions, de sorte que les charges utiles d'erreur (qui contiennent souvent des données utilisateur) restent sur votre infrastructure.
• Bilans de santé + alertes de disponibilité. Cipi 5 contrôles de santé de l'application du navire ; associez-les à un moniteur de disponibilité externe pour la vue extérieure.
• Regardez les journaux d'authentification. Rapports Fail2ban et lastb je te dirai qui frappe.
• Ayez un plan d’intervention avant d’en avoir besoin : isoler la boîte, faire pivoter chaque secret (y compris les implications APP_KEY pour les données chiffrées), restauration à partir d'un instantané connu (cipi backup run couvre les instantanés programmés ; Cipi 5 ajoute des instantanés de base de données avant le déploiement), identifier le point d’entrée, puis rédiger l’autopsie. Ne jamais patcher et prier sur un live compromis hôte.

Questions fréquemment posées

Continuez à lire