Quatre gros hacks
Les quatre hacks des services publics peuvent être regroupés en deux vecteurs : faille applicative, et usurpation d'accès.
- FICOBA, janvier 2026. Identifiants d'un fonctionnaire. 1,2 million de comptes bancaires.
- ANTS, avril 2026. Faille de conception dans le portail. 11,7 millions de comptes usagers.
- DGFIP, juin 2026. Accès VPN par usurpation d'identifiants. 678 438 lignes.
- Éducation nationale, juillet 2026. Compte professionnel usurpé. 43 Go revendiqués.
Pour l'ANTS, c'est quand même assez abusé : si votre dossier est accessible sur /dossier/1234, vous pouviez changer l'identifiant dans l'adresse pour accéder au dossier 1233 ou 1235.
Ça s'appelle une référence directe non sécurisée (ou IDOR pour Insecure Direct Object Reference). C'est la faille la plus banale du métier.
À noter, la DGFIP a reconnu avoir vu passer l'attaque dès fin juin et coupé les accès, mais a attendu que le hacker la revendique, six semaines plus tard, avant de nous prévenir. À croire qu'ils n'avaient pas compris que le pirate avait sorti des données.
Le RGPD (article 34) impose d'informer les personnes concernées "dans les meilleurs délais". À priori, deux mois, ça passe.
Bref, on ne les changera pas, mais c'est la bonne occasion pour chercher à lister quelques bonnes pratiques.
Deux types d'attaques
Quand quelqu'un vous vise
L'attaquant a choisi sa cible, vous. Il sait ce qu'il cherche.
Il y a rarement besoin d'une prouesse technique comme on en voit dans les films (mention spéciale à Opération Espadon, la scène la plus ridicule d'Hollywood).
En général, il suffit d'un mot de passe volé ailleurs, d'un mail de phishing, ou du compte d'ancien salarié resté ouvert. C'est ce qui s'est passé trois fois sur quatre cet été.
Ce qu'il veut, ce sont vos données : des noms, des dates de naissance, des adresses, des numéros de téléphone. Ça se revend, et ça sert à monter des arnaques crédibles.
Quand personne ne vous vise
Des robots scannent Internet en permanence. Ils cherchent des sites qui tournent sur une vieille version d'un CMS connu, ou des logiciels avec une configuration par défaut trop permissive.
Ils ne savent pas qui vous êtes. Ce qui les intéresse, c'est votre serveur. Ils posent des liens vers d'autres sites, envoient du spam, hébergent une fausse page de banque ou une boutique de contrefaçons.
Enregistrez un nom de domaine, faites-le pointer vers un serveur quelconque, attendez quarante secondes : les scans commencent. C'est du scan de masse. Personne ne vous a choisi, vous êtes juste une adresse dans une liste.
Ces robots cherchent une faille publique dans un logiciel répandu. Une application sur mesure n'est pas dans leur liste, mais elle n'est pas indestructible : le framework utilisé (boîte à outils de développement), son serveur web et ses dépendances y sont, eux. On les surveille, et on les tient à jour.
Défense en profondeur : on empile les couches
Aucune mesure ne suffit toute seule. On en met plusieurs, chacune prévue pour le cas où la précédente lâche.
Réduire la surface d'attaque : on ferme ce qui ne sert pas
Un serveur, c'est une machine avec des portes. Chaque porte ouverte est une porte à surveiller. Moins il y en a, mieux on dort.
Le pare-feu bloque tout par défaut. On ouvre ensuite ce dont on a besoin, et rien d'autre. Pour une application web, ça fait deux portes : le web pour les utilisateurs, l'administration pour l'infogérant.
La base de données n'a pas besoin d'être joignable depuis Internet. Elle écoute en local, sur la machine. Personne ne peut s'y connecter de l'extérieur.
L'accès d'administration se limite aux adresses de l'infogérant. Une porte ouverte à trois machines connues, pas au monde entier.
Le cloisonnement : chaque application dans sa boîte
On met souvent plusieurs choses sur le même serveur. Un site vitrine, une application métier, parfois un outil interne.
Ils doivent être séparés. Chacune a son utilisateur système, sa base de données, son espace disque. Elles ne se voient pas.
Si le site vitrine se fait avoir par un robot, l'application métier reste intacte. Sans cette séparation, une faille sur le site le plus exposé ouvre l'accès à tout le reste.
Le mot de passe ne suffit plus
Trois hacks sur quatre cet été sont passés par un compte légitime. Le mot de passe seul ne protège rien.
La double authentification ajoute un code temporaire, généré sur le téléphone. Voler le mot de passe ne suffit plus, il faut aussi le téléphone.
Chacun a son propre compte. Pas de compte partagé entre plusieurs personnes, sinon plus personne ne sait qui fait quoi.
Le jour où quelqu'un quitte l'entreprise, on coupe son accès. C'est évident, et c'est ce qu'on oublie le plus souvent.
Le contrôle d'accès : on vérifie les droits à chaque fois
Le cas de l'ANTS était une adresse qu'on pouvait modifier à la main. C'est le piège classique.
Un document ne doit jamais être servi directement. Pas de lien du type monsite.fr/documents/1234.pdf qui s'ouvre pour qui le connaît. Le fichier est rangé ailleurs, hors de l'espace public. L'application le récupère, vérifie que la personne a le droit de le voir, et l'affiche.
Le contrôle se fait à chaque affichage, pas juste une fois à la connexion.
Chacun reçoit les droits dont il a besoin, et pas plus : c'est le principe du moindre privilège. Un commercial n'a rien à faire dans les dossiers RH.
OWASP : ne pas réinventer la roue
Ces problèmes sont connus et documentés. L'OWASP (Open Worldwide Application Security Project) est une organisation qui publie depuis 2003 la liste des dix risques les plus répandus sur les applications web, la Top Ten Web Application Security Risks. C'est une référence dans le métier.
Dans la version 2025, le contrôle d'accès défaillant occupe la première place. Cent pour cent des applications testées en présentaient une forme. La liste cite explicitement le fait de consulter le dossier d'un autre en changeant son identifiant dans l'adresse.
C'est exactement le cas de l'ANTS. Onze millions de comptes exposés par le risque numéro un d'une liste publique.
Le reste du classement 2025 est du même ordre : mauvaise configuration, dépendances compromises, chiffrement défaillant, injections. Rien d'exotique.
Un prestataire qui construit une application métier connaît cette liste et travaille avec.
Se faire tester par des experts indépendants
On ne valide pas la sécurité de sa propre maison : on a forcément des angles morts. Faire intervenir un cabinet externe pour simuler une attaque (un test d'intrusion ou pentest - penetration testing) permet de tester l'application en conditions réelles. S'ils trouvent une faille, on la corrige avant qu'un pirate ne tombe dessus.
La minimisation : on garde le moins de données possible
Une donnée qu'on ne stocke pas ne peut pas fuiter. C'est un peu le principe de la privacy by design. Le RGPD demande de ne collecter que ce dont on a besoin, et de ne pas le garder indéfiniment. C'est aussi une mesure de sécurité.
Concrètement, on se pose deux questions pour chaque champ :
- Est-ce qu'on en a vraiment l'usage ?
- Combien de temps on le garde ?
Un fichier de candidatures illustre bien le principe. Le numéro de sécurité sociale n'a rien à y faire tant que personne n'est embauché. Les candidatures non retenues se purgent au bout de deux ans. Passé ce délai, l'application les supprime toute seule.
Ça réduit le préjudice en cas d'incident. Une base de trois mille fiches à jour fait moins de dégâts qu'une base de quarante mille qui remonte à 2009.
C'est ce qui a aggravé le hack de l'Éducation nationale. Certains fichiers dérobés contenaient des données remontant au début des années 2000.
On surveille ce qu'on n'a pas pu empêcher
Il faut partir du principe que quelqu'un finira par entrer. La question devient : combien de temps avant qu'on s'en aperçoive.
Consulter cinquante fiches en une minute, ce n'est pas un usage humain. On plafonne le nombre d'actions par compte et par minute. Au-delà, l'application bloque et envoie une alerte.
C'est ce qui a manqué à la DGFIP. Leur surveillance guettait les gros volumes. L'attaquant est passé à côté en allant lentement.
Le journal d'audit enregistre qui a consulté, modifié ou exporté quoi, et quand. Il se lit, il ne se modifie pas, même depuis un compte administrateur compromis.
Sans ce journal, après un incident, on ne sait pas ce qui est sorti. On l'apprend en même temps que tout le monde.
Ce qu'on oublie souvent
La base de production reste en production. On ne la copie pas sur la préprod, ni sur le poste du développeur, ni dans un environnement de démonstration. Ces endroits sont moins protégés, et une base qui circule finit par traîner quelque part. Le développement se fait sur des données inventées.
Les sauvegardes sont chiffrées. Une sauvegarde volée reste illisible.
Les mises à jour du framework et des dépendances se font en continu. C'est ce qui ferme les portes que cherchent les robots.
Ce qu'on peut raconter après coup
Une application bien tenue, c'est une application dont on peut reconstituer l'histoire.
Qui s'est connecté, quand, ce qu'il a consulté, ce qu'il a exporté. En cas de problème, on sait quoi dire aux personnes concernées, et on le sait vite.
La DGFIP a mis six semaines. Elle a appris ce qui était sorti en lisant un forum.
Le jour où ça arrive, avoir un plan
Le risque zéro n'existe pas en informatique. La vraie différence entre un incident maîtrisé et un désastre comme celui de la DGFIP, c'est la vitesse de réaction.
Quand une anomalie est détectée, la procédure est déjà écrite : isolation immédiate des accès compromis, analyse du journal d'audit et information transparente des clients sous 24 à 48 heures. Pas deux mois plus tard.