Sécurité d’un site web : organiser les protections et la continuité du service

1. Établir ce que le site doit protéger

Le point de départ est un inventaire exploitable. Relevez les noms de domaine, l’hébergement, les applications, extensions, bibliothèques, services tiers, formulaires, données collectées et personnes habilitées à publier. Pour chaque élément, indiquez un responsable et la manière de le mettre à jour ou de le remplacer.

Classez ensuite les conséquences d’une indisponibilité, d’une modification non autorisée ou d’une fuite de données. Le niveau de protection dépend de ces effets réels : un site vitrine sans compte utilisateur ne présente pas les mêmes enjeux qu’un service qui reçoit des dossiers ou gère des commandes. Cette distinction évite autant l’oubli que la surenchère technique.

• Noter où résident les contenus, les fichiers envoyés et les sauvegardes.
• Identifier les dépendances nécessaires à une page ou à un formulaire important.
• Repérer les accès humains et les comptes techniques sans recopier leurs secrets dans l’inventaire.
• Définir les parcours qui doivent rester utilisables en priorité.

2. Réduire les causes d’incident ordinaires

Un composant non maintenu, des droits trop larges ou une configuration incohérente peuvent exposer un site même lorsque son interface semble fonctionner. Organisez les mises à jour selon leur criticité, testez-les dans un environnement adapté et gardez une procédure de retour arrière. Les personnes chargées de publier n’ont besoin que des permissions correspondant à leur rôle.

Les protections techniques doivent être cohérentes avec l’application : transport chiffré, validation des entrées, gestion sûre des sessions, configuration des en-têtes et dépendances maîtrisées. Le guide de l’ANSSI sur la sécurité côté navigateur et les référentiels OWASP aident à choisir les contrôles pertinents. Une simple liste d’en-têtes ne prouve pas que les parcours sont protégés.

• Réviser périodiquement les comptes et retirer les accès devenus inutiles.
• Contrôler les composants exposés et documenter les versions déployées.
• Vérifier les formulaires et interfaces qui acceptent des données ou exécutent des actions.
• Relier chaque protection à un risque identifié et à un test observable.

Point de vigilanceCe guide traite de l’organisation du contrôle ; il ne remplace pas un audit de sécurité adapté à l’application et à ses données.

3. Préparer une restauration réelle

Une sauvegarde n’a de valeur opérationnelle que si son contenu, sa fréquence et sa restauration correspondent au besoin. Les fichiers seuls ne suffisent pas si la base de données, les médias, la configuration ou les redirections nécessaires à la reprise manquent. Conservez des copies séparées du système de production selon une durée de conservation définie.

Programmez un exercice de restauration sur un environnement isolé. Mesurez le temps nécessaire, vérifiez les contenus et les fonctions critiques, puis notez les étapes qui ont échoué. Cette preuve permet de corriger le dispositif avant qu’un incident n’impose de l’utiliser.

• Définir ce qui est sauvegardé et la fréquence acceptable de perte de données.
• Protéger l’accès aux copies et vérifier leur intégrité.
• Documenter les dépendances nécessaires pour redémarrer le site.
• Tester la reprise et conserver le résultat du test.

4. Détecter et qualifier un problème

Surveillez les signes utiles : indisponibilité, erreurs répétées, échec de publication, changement inattendu de fichiers ou de comptes, et dégradation d’un formulaire essentiel. Les journaux doivent aider à comprendre un événement sans collecter ou exposer plus de données que nécessaire.

Définissez un circuit court : qui reçoit l’alerte, qui peut décider d’une mise hors ligne ou d’un retour arrière, qui vérifie les faits et qui informe les personnes concernées. En cas de données personnelles, les obligations applicables doivent être évaluées avec les responsables compétents. Évitez d’attribuer trop vite une cause avant d’avoir préservé les éléments utiles au diagnostic.

• Relier chaque alerte à une personne et à une action possible.
• Conserver l’heure, l’impact et les décisions prises pendant l’incident.
• Isoler la correction, puis retester les parcours prioritaires.
• Mettre à jour la procédure après le retour d’expérience.

5. Installer une routine de contrôle proportionnée

Une revue avant mise en ligne contrôle les droits, les formulaires, les dépendances, les sauvegardes, les redirections et les en-têtes. Une revue régulière suit les changements intervenus depuis la publication. Une revue plus profonde est justifiée après une migration, une nouvelle intégration ou un incident.

Gardez pour chaque contrôle un résultat, une date et un responsable. Le but n’est pas d’accumuler des cases cochées, mais de pouvoir expliquer ce qui a été vérifié, ce qui reste incertain et quand la décision sera réexaminée.

• Avant publication : tester les parcours sensibles et la possibilité de retour arrière.
• Chaque mois ou après changement : examiner mises à jour, alertes et comptes.
• À intervalles définis : restaurer une copie et revoir les dépendances.
• Après incident : corriger la cause et vérifier l’efficacité de la mesure.

Quelle première action selon la situation ?

Avant d’avancer

La check-list opérationnelle

1. ✓Un responsable est désigné pour le domaine, l’hébergement, l’application et les sauvegardes.
2. ✓Les composants et services tiers actifs sont inventoriés.
3. ✓Les droits de publication et d’administration sont revus.
4. ✓Les mises à jour sont testées avec une possibilité de retour arrière.
5. ✓Les formulaires et actions sensibles sont contrôlés.
6. ✓Les sauvegardes couvrent données, médias et configuration nécessaires.
7. ✓Une restauration a été réellement testée.
8. ✓Les alertes et la procédure d’incident ont un destinataire identifié.
9. ✓Les décisions et écarts restants sont datés.