Sécurité d'une application métier : les huit points que nous vérifions systématiquement

Les failles que nous rencontrons en audit ne sont presque jamais sophistiquées. Ce sont les mêmes, année après année, et elles relèvent de l’oubli plutôt que de l’attaque élaborée.

Voici la liste que nous passons avant chaque mise en production. Elle n’a rien d’original — c’est précisément ce qui fait son intérêt.

1. L’authentification, jamais réimplémentée

La règle : utiliser un composant éprouvé et maintenu, ou un fournisseur d’identité. Jamais d’implémentation maison.

Le stockage des mots de passe, la gestion des sessions, la réinitialisation, la limitation des tentatives, la double authentification : chacun de ces points a ses pièges, et ils ont tous été résolus. Les réimplémenter, c’est refaire les erreurs de tout le monde, en moins bien testé.

Ce que nous vérifions : un algorithme de hachage adapté aux mots de passe, des sessions invalidées côté serveur à la déconnexion, une limitation du nombre de tentatives, et une réinitialisation qui ne révèle pas si un compte existe.

2. Le contrôle d’accès, vérifié côté serveur

La règle : chaque requête vérifie que l’utilisateur a le droit d’accéder à cette ressource précise, pas seulement qu’il est authentifié.

C’est de loin la faille la plus fréquente sur les applications métier, et la plus facile à exploiter. Le menu ne montre pas le bouton, donc on suppose que l’accès est protégé. Mais l’adresse existe, et changer un identifiant dans l’URL suffit à consulter le dossier d’un autre.

Ce que nous vérifions : pour chaque point d’entrée, le droit est-il vérifié côté serveur et porte-t-il sur l’objet demandé ? Nous testons systématiquement en modifiant les identifiants avec un compte peu privilégié.

3. Le cloisonnement entre organisations

La règle : sur une application multi-clients, le filtre d’appartenance ne doit pas dépendre de la vigilance du développeur.

Une seule requête qui oublie la condition, et les données d’une organisation deviennent visibles par une autre. C’est l’incident le plus grave qui puisse arriver à une application métier, et il tient à une clause manquante.

Ce que nous mettons en place : le filtre appliqué au niveau de la couche d’accès aux données, pas dans chaque requête, avec des tests automatiques qui vérifient qu’un utilisateur d’une organisation ne peut jamais lire les données d’une autre.

Photo : George Becker — licence CC0.

4. Le chiffrement, en transit et au repos

La règle : HTTPS partout, sans exception ni page oubliée. Chiffrement au repos pour les données sensibles, et sauvegardes chiffrées.

Ce que nous vérifions : redirection systématique, en-têtes de sécurité corrects, et surtout le chiffrement des sauvegardes — c’est le point le plus souvent négligé, alors qu’une sauvegarde est une copie complète de la base qui circule et se stocke.

5. La journalisation des accès sensibles

La règle : savoir qui a consulté ou modifié quoi, et quand.

Ce n’est pas seulement une exigence de conformité. C’est ce qui permet de répondre à la question « que s’est-il passé ? » après un incident. Sans journal, l’analyse est impossible et l’on ne peut ni mesurer l’ampleur, ni informer correctement les personnes concernées.

Le piège : journaliser des données personnelles ou des secrets dans les traces techniques. Les journaux sont souvent moins protégés que la base — et ils partent parfois chez un prestataire d’observabilité.

6. Les secrets hors du code

La règle : aucun mot de passe, clé d’API ou certificat dans le dépôt, même privé.

Ce que nous vérifions : les secrets sont injectés par l’environnement, une analyse automatique détecte les fuites accidentelles, et l’historique du dépôt est vérifié — un secret supprimé reste présent dans les commits précédents, donc doit être révoqué et non simplement effacé.

Photo : Leeroy — licence CC0.

Photo : domaine public (CC0).

7. Les mises à jour de dépendances, automatisées

La règle : la surveillance des vulnérabilités et la proposition de mises à jour doivent être automatiques. Un processus manuel n’est pas exécuté.

Ce que nous mettons en place : une analyse quotidienne des dépendances, des propositions de montée de version automatiques, et une règle de traitement — les correctifs de sécurité critiques passent en priorité sur le fonctionnel, sans discussion.

8. La restauration, testée pour de vrai

La règle : une sauvegarde non restaurée n’est pas une sauvegarde. C’est une hypothèse.

Ce que nous faisons : une restauration complète en environnement isolé, à intervalle régulier, chronométrée. Cela vérifie que les fichiers sont exploitables, que la procédure est juste, et cela donne un délai réel de remise en service — le seul chiffre qui compte le jour où ça arrive.

Les deux erreurs les plus fréquentes

Confondre l’interface et la protection. C’est le point 2, et c’est la faille la plus répandue. Elle vient d’une bonne intention : on masque ce que l’utilisateur ne doit pas voir, et on croit avoir sécurisé.

Considérer que « c’est interne, donc ce n’est pas exposé ». Une application accessible uniquement en interne reste accessible à tous les salariés, aux prestataires, et à quiconque obtient un accès au réseau. Le modèle de menace ne se limite pas à internet.

Ce qui arrive vraiment, en pratique

Les incidents que nous rencontrons ne ressemblent pas à ceux qu’on imagine. Trois scénarios couvrent la quasi-totalité des cas réels.

Un compte compromis par réutilisation de mot de passe. L’utilisateur emploie ailleurs le même mot de passe, cet autre service subit une fuite, et l’attaquant se connecte normalement. Aucune faille applicative n’est en cause. La seule parade efficace est le second facteur sur les comptes à privilèges.

Un accès resté ouvert après un départ. Un prestataire, un ancien salarié, un compte de service créé pour un besoin ponctuel. C’est le scénario le plus fréquent, et il ne relève pas de la technique mais du processus de sortie.

Une dépendance vulnérable non mise à jour. La faille est publique, l’outillage d’exploitation aussi, et le délai entre la publication et les premières tentatives se compte en jours. C’est exactement pourquoi la mise à jour automatisée des dépendances figure dans la liste.

Ce qu’il faut avoir écrit avant l’incident

Le jour où quelque chose arrive, personne n’improvise correctement. Une page suffit, et elle doit exister à l’avance.

Qui décide. Une personne nommée, avec un suppléant. La première perte de temps dans un incident est toujours la recherche de celui qui a autorité pour couper un service.

Comment on coupe. La procédure exacte pour suspendre l’accès, révoquer les sessions en cours et réinitialiser les secrets. Écrite, testée une fois.

Qui prévenir, et sous quel délai. Une violation de données personnelles impose une notification à l’autorité de contrôle sous soixante-douze heures. Ce délai court à partir de la prise de connaissance, pas de la fin de l’analyse — beaucoup de gens le découvrent au mauvais moment.

Ce qu’on conserve. Les journaux sont la seule matière permettant de reconstituer ce qui s’est passé. Le réflexe de tout redémarrer proprement détruit précisément ce dont on aura besoin.

Ce que cette liste ne remplace pas

Elle ne remplace pas un test d’intrusion sur une application réellement critique, ni une analyse de risque adaptée à votre secteur.

Mais dans mon expérience, une application qui passe correctement ces huit points est déjà au-dessus de la grande majorité de ce que nous auditons. Les attaques sophistiquées existent ; elles sont beaucoup plus rares que les identifiants qu’on peut incrémenter dans une URL.