Maintenir une surface minimale et à jour

Inventoriez le code, les dépendances, extensions, comptes et services externes. Supprimez ce qui n’est plus utilisé et appliquez les mises à jour selon une procédure testée. L’ANSSI rappelle que les logiciels non mis à jour deviennent vulnérables et recommande de télécharger les mises à jour depuis les sources officielles.

Désactivez les environnements, interfaces et fichiers de diagnostic non nécessaires en production. Ne publiez pas de secrets dans le code ou le dépôt. Utilisez des versions supportées du langage, du serveur et des bibliothèques.

Sécuriser les accès et les données

Attribuez des comptes nominatifs, le minimum de droits et une authentification multifacteur lorsque possible. Séparez administration, déploiement et consultation. Révoquez rapidement les accès qui ne sont plus nécessaires et contrôlez les journaux de connexion.

Chiffrez les échanges avec HTTPS, minimisez les données collectées et protégez celles qui sont stockées. Les sauvegardes doivent être séparées, chiffrées lorsque nécessaire et testées par une restauration. Une sauvegarde jamais restaurée reste une hypothèse.

  • Mots de passe uniques et gestionnaire adapté.
  • Double authentification sur les accès critiques.
  • Droits minimaux et revue périodique des comptes.
  • Sauvegardes isolées avec tests de restauration.
  • Secrets stockés hors du code public.

Protéger l’application et le navigateur

Validez toutes les entrées côté serveur, échappez les sorties selon leur contexte et utilisez des requêtes paramétrées. Protégez les formulaires contre la falsification de requête, l’abus et l’injection. Limitez les tailles, fréquences et types de fichiers.

Les en-têtes navigateur complètent ces contrôles. Le guide de l’ANSSI consacré à la sécurité côté navigateur traite notamment de Content Security Policy, Referrer-Policy et de l’isolation des ressources. Configurez-les en fonction du site et testez leur effet : une politique copiée sans validation peut bloquer des fonctions ou rester trop permissive.

Surveiller et préparer la réponse

Centralisez les erreurs importantes, surveillez les changements de fichiers, les échecs répétés, les volumes inhabituels et les certificats. Définissez qui reçoit les alertes et comment qualifier un incident. Conservez des journaux utiles sans enregistrer inutilement des données sensibles.

Préparez une procédure de mise hors ligne, de restauration, de rotation des secrets et de communication. Après un incident, corrigez la cause, vérifiez l’étendue, documentez les décisions et réévaluez les contrôles. La résilience fait partie de la sécurité.

Sources et références utiles

Ces ressources officielles complètent les explications présentées dans cet article.

Questions fréquentes

À retenir avant de décider

HTTPS suffit-il à sécuriser un site ?

Non. HTTPS protège les échanges en transit. Il ne corrige pas une vulnérabilité applicative, un mot de passe compromis, une extension obsolète ou une mauvaise configuration.

À quelle fréquence faut-il mettre à jour ?

Surveillez en continu les versions et alertes, puis appliquez rapidement selon la criticité et après les vérifications adaptées. Les composants exposés et vulnérabilités actives sont prioritaires.

Quels en-têtes de sécurité utiliser ?

Le choix dépend du site. CSP, HSTS, X-Content-Type-Options, Referrer-Policy et des politiques d’isolation sont courants. Configurez-les progressivement et vérifiez les erreurs dans le navigateur.