La sécurité n'est pas un produit que l'on achète une fois pour l'oublier. C'est un petit ensemble d'habitudes appliquées de façon cohérente. La bonne nouvelle : la plupart des sites web et applications web d'entreprise peuvent couvrir l'essentiel des risques réalistes avec une poignée de pratiques de base.
HTTPS et gestion des certificats
Chaque page doit se charger en HTTPS. Ce n'est plus un agrément, navigateurs, utilisateurs et moteurs de recherche traitent tous le HTTP comme cassé. Redirigez le HTTP vers le HTTPS, renouvelez les certificats automatiquement (la plupart des hébergeurs le font gratuitement), et vérifiez que les avertissements de contenu mixte ont disparu.
Une authentification bien faite
- Utilisez des mots de passe ou phrases de passe longs, pas des mots de passe courts et complexes.
- Activez l'authentification à deux facteurs (2FA) pour tout ce qui compte, panneaux d'administration, comptes d'hébergement, e-mail, outils de paiement.
- Utilisez un gestionnaire de mots de passe dans l'équipe, pas un tableur partagé.
- Supprimez les comptes quand les gens partent. Les comptes "dormants" sont un point d'entrée courant.
Accès administrateur
Les URL d'administration ne devraient pas être devinables depuis l'extérieur. Limitez le débit des tentatives de connexion, journalisez les tentatives échouées, et envisagez une couche supplémentaire (liste d'IP autorisées ou VPN) pour les panneaux hautement sensibles.
Mises à jour logicielles
La plupart des vulnérabilités publiques sont corrigées rapidement après divulgation ; le risque réel, c'est de faire tourner un logiciel qui n'a pas été mis à jour depuis des mois. Maintenez à jour le framework, le CMS, les plugins, le runtime et les bibliothèques. Planifiez des mises à jour de routine au lieu de ne les faire qu'après un incident.
Traitement sécurisé des entrées utilisateur
- Validez côté serveur, pas seulement dans le navigateur, tout ce qui vient du client peut être modifié.
- Utilisez des requêtes paramétrées ou un ORM correct pour prévenir l'injection SQL.
- Échappez correctement les sorties pour prévenir le cross-site scripting (XSS).
- Limitez les fichiers que les utilisateurs peuvent téléverser, et où ils vont.
- Limitez le débit des formulaires et points de terminaison que les attaquants ciblent (connexion, inscription, contact).
Secrets et configuration
- Ne codez pas en dur les mots de passe, clés d'API ou jetons dans le code source.
- Conservez-les dans des variables d'environnement ou un gestionnaire de secrets, pas validés dans le dépôt.
- Faites tourner les secrets quand quelqu'un part, ou après tout incident.
Sauvegardes et restauration
Une sauvegarde n'est pas une sauvegarde tant qu'elle n'a pas été restaurée. Des sauvegardes régulières et automatisées sont essentielles, mais une procédure testée pour les restaurer l'est tout autant. Les rançongiciels et suppressions accidentelles finissent par arriver à tout le monde.
Surveillance et journaux
Vous ne pouvez pas réagir à ce que vous ne voyez pas. Au minimum, conservez les journaux du serveur, capturez les erreurs applicatives, et configurez des alertes sur les pics inhabituels de réponses 401/403/500. C'est ainsi que vous découvrez une attaque tôt plutôt qu'après coup.
Confidentialité et conformité
- Ne collectez que les données dont vous avez réellement besoin.
- Ayez une politique de confidentialité claire et un consentement aux cookies qui reflète la réalité, pas un modèle copié ailleurs.
- Comprenez quelles données sont réglementées (paiement, santé, données personnelles au titre du RGPD) et traitez-les en conséquence.
Erreurs courantes
- Des audits de sécurité qui s'arrêtent au rapport. Les constats doivent être corrigés et vérifiés, pas seulement archivés.
- "Nous sommes trop petits pour être une cible". La plupart des attaques sont automatisées et cherchent n'importe quel système non corrigé.
- Traiter les mots de passe comme toute l'histoire. 2FA, mises à jour, sauvegardes et surveillance comptent plus que les règles de complexité des mots de passe.
- Une seule personne détenant toutes les clés. Les accès critiques devraient avoir un responsable de secours, documenté clairement.
