Sécurité des applications web : les recommandations concrètes du CERT‑FR

Le CERT‑FR a publié un retour d’expérience riche en constats de terrain et en bonnes pratiques pour réduire les fuites de données dans les applications web. Au-delà des exigences d’homologation RGS, il propose des mesures techniques et organisationnelles applicables dès aujourd’hui.

Chiffrement des supports de stockage

Un incident chez un fournisseur de télétransmission médicale a montré que la moindre erreur de maintenance peut exposer des dossiers patients. La réponse du CERT‑FR consiste à chiffrer systématiquement les disques, même après usage. Sous Linux, l’association de Clevis et LUKS permet de lier le disque au TPM, avec un serveur Tang pour le déverrouillage à distance. Sous Windows, la combinaison BitLocker et le service Network Unlock offre un équivalent. Ces solutions garantissent que les données restent illisibles en cas d’extraction physique.

Gestion des adresses IP et des en‑têtes HTTP

Des configurations ont parfois laissé des adresses IP publiques à l’intérieur d’infrastructures privées. Tant que le routage reste strictement segmenté, le risque est limité, mais cela complique l’analyse des flux et peut provoquer des erreurs dans certains pare‑feux. Le CERT‑FR recommande de respecter les plages privées définies par la RFC 1918.

Pour limiter l’exposition, il conseille de différencier les services par nom d’hôte plutôt que par chemin d’URL : https://admin.example.com est plus facile à filtrer que https://www.example.com/admin. Cette séparation facilite l’application de politiques de filtrage distinctes et réduit les partages de données involontaires entre services.

En complément, il faut enrichir les requêtes HTTP avec des en‑têtes conservant l’origine de la connexion, comme X‑Forwarded‑For. L’adresse IP doit également être consignée dans les journaux des pare‑feu, VPN et équipements périmétriques, par exemple via le champ remoteip. Cela aide à retracer les sources d’attaque et à détecter des comportements anormaux.

Utilisation des en‑têtes pour la détection d’anomalies

Le CERT‑FR rappelle que les attaquants laissent souvent des traces dans les en‑têtes, comme un User‑Agent caractéristique d’une bibliothèque Python. Un tel profil peut indiquer que les identifiants d’un compte ont été compromis. En combinant le filtrage d’adresse IP et l’analyse des en‑têtes, on augmente la visibilité sur les tentatives d’accès non autorisées.

Protection des cookies de session avec le standard DBSC

Le W3C travaille sur le standard Device Bound Session Credentials (DBSC), qui lie les cookies de session à une paire de clés stockée dans le TPM du navigateur. Chrome implémente déjà ce mécanisme. Tant que le standard n’est pas largement adopté, le CERT‑FR recommande de réduire la durée de vie des cookies, d’utiliser les attributs HttpOnly et Secure, et de privilégier des solutions comme les passkeys ou le zero‑trust.

Approche Zero‑Trust

Le modèle Zero‑Trust vise à ne plus faire confiance à un simple couple login/mot de passe. Le CERT‑FR propose de déployer des bi‑clés ou des certificats TLS dans les navigateurs des postes clients. Cette méthode reste vulnérable aux logiciels de vol d’informations (infostealers) capables d’extraire des certificats non protégés par du matériel de sécurité. En pratique, lier la session aux conditions d’utilisation (adresse IP, appareil, etc.) renforce la résilience, surtout pour les utilisateurs mobiles dont l’adresse IP varie fréquemment.

Journalisation précise

De nombreux serveurs UNIX n’enregistrent que des horodatages à la seconde, voire sans date. Le CERT‑FR recommande d’adopter le format Syslog RFC 5424 avec une précision à la milliseconde et d’harmoniser le fuseau horaire (GMT). Une source de temps unique pour tous les équipements assure la corrélation des événements et facilite les investigations.

Désactivation des services inutiles

Il est fréquent de trouver des services d’administration (SNMP, consoles web, etc.) qui écoutent sur toutes les interfaces réseau. Le CERT‑FR incite à restreindre chaque service à l’interface strictement nécessaire et à désactiver les services non utilisés. Bloquer les accès Internet vers les consoles d’administration, notamment celles différenciées uniquement par un chemin /admin, doit se faire au niveau du WAF ou du proxy inverse.

Alignement des règles WAF avec la logique applicative

Pour définir des seuils de détection d’anomalies, il faut travailler avec les métiers et refléter la logique métier dans les requêtes. Des seuils simples (volume de données par session, source IP) sont faciles à mettre en place, mais les règles plus fines, qui corrèlent groupes d’utilisateurs et accès aux objets, nécessitent une structure de requête alignée sur l’application. Sans cet alignement, l’analyse devient lourde et les frontaux peuvent devenir des points de déni de service.

En appliquant ces recommandations, les équipes peuvent réduire significativement le risque de fuite de données, améliorer la traçabilité des incidents et préparer leurs infrastructures à l’adoption future de standards comme DBSC. Le passage à une architecture Zero‑Trust, soutenue par une journalisation fine et un chiffrement systématique, constitue aujourd’hui une feuille de route réaliste pour les organisations publiques et privées soucieuses de protéger leurs applications web.