Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-306 : authentification manquante sur une fonction critique

CWE-306 : authentification manquante sur une fonction critique

Section intitulée « CWE-306 : authentification manquante sur une fonction critique »

Vingt-et-unième du CWE Top 25 2025. Le libellé officiel est Missing Authentication for Critical Function, « authentification manquante pour une fonction critique ». Deux mots de cette formule font tout le travail, et ce ne sont pas ceux qu’on croit : « critique », qui délimite, et « manquante », qui exclut les authentifications simplement mauvaises.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Section intitulée « Ce que la classe recouvre exactement »

Le produit n’effectue aucune authentification pour une fonctionnalité qui exige une identité prouvable de l’utilisateur, ou qui consomme une quantité significative de ressources.

Deux précisions de la définition sont souvent ignorées. La première est le critère de criticité : le catalogue ne reproche pas d’offrir des pages publiques, il reproche de laisser sans authentification une fonction qui exige une identité. La seconde est plus surprenante et mérite d’être signalée : la consommation significative de ressources suffit à rendre une fonction critique. Une opération coûteuse ouverte à tous (un export massif, un calcul lourd, une génération de document) relève de cette classe même si elle ne divulgue rien, parce qu’elle permet d’épuiser le service. Elle rejoint par là l’allocation de ressources sans limite, au rang 25.

La frontière avec l’autorisation manquante est la distinction la plus utile du voisinage : l’authentification établit qui parle, l’autorisation décide ce qu’il peut faire. CWE-306 désigne l’absence de la première question. Une interface d’administration qui répond à n’importe qui sans demander d’identité relève de cette classe ; une interface qui demande une identité, l’obtient, et ne vérifie pas les droits relève de l’autre.

Sa place dans l’arbre

Section intitulée « Sa place dans l’arbre »

CWE-306 est une base, fille de la classe CWE-287, « authentification incorrecte » au sens large. Deux entrées filles la précisent, et elles décrivent les deux situations réellement rencontrées :

  • CWE-288, le contournement d’authentification par un chemin alternatif : la fonction est protégée par l’interface principale et accessible par une autre voie : une API qui double la page web, un port de gestion, un service de diagnostic, une interface de secours. C’est le cas dominant, et il explique pourquoi cette classe survit aux audits : la porte vérifiée est bien fermée ;
  • CWE-322, l’échange de clés sans authentification de l’entité : deux parties établissent un canal chiffré sans vérifier à qui elles parlent. Le chiffrement est parfait, l’interlocuteur est inconnu : ce qui rend l’attaque de l’intercepteur triviale.

Pourquoi elle est si haut

Section intitulée « Pourquoi elle est si haut »

Parce que les équipements l’intègrent par conception. Imprimantes, caméras, automates, enregistreurs, interfaces de gestion hors bande : une partie significative de ces appareils expose des fonctions d’administration sans authentification, ou avec une authentification contournable par un chemin secondaire. Le site documente le cas des imprimantes réseau, qui est exemplaire : un équipement banal, des fonctions critiques, aucune identité demandée.

Parce que les services internes supposent un réseau de confiance. Base de données, file de messages, cache distribué, tableau de bord de supervision : beaucoup sont livrés sans authentification par défaut, au motif qu’ils n’écoutent que sur le réseau interne. La supposition tombe dès qu’un conteneur mal configuré, un service exposé par erreur ou une requête côté serveur permet de les joindre. Dans un cluster, le jeton de compte de service monté par défaut illustre la même supposition sous une autre forme.

Parce que l’annuaire garde des portes ouvertes historiques. Le site traite les deux cas canoniques : le bind anonyme et le bind simple en clair, à désactiver, et ce qu’un annuaire laisse énumérer sans aucune authentification quand on ne l’a pas fait.

Parce qu’elle se découvre en une requête. Un balayage réseau suffit à constater qu’un service répond sans identité ; la détection est triviale, donc le signalement abondant, ce que le classement enregistre.

Le mécanisme, et où le site le traite

Section intitulée « Le mécanisme, et où le site le traite »

Il n’y a pas de mécanisme à décrire : il n’y a rien. Ce que le site traite, ce sont les décisions qui évitent ce vide. Gouverner les facteurs d’authentification en entreprise pose la question du niveau exigé selon la fonction, et les niveaux d’assurance d’authentification disent ce qu’il faut pour monter d’un cran : car « authentifié » n’est pas binaire.

Pour les fonctions les plus sensibles, déployer FIDO2 pour les comptes à privilèges décrit le niveau attendu sur une interface d’administration. Et pour le cas des machines, qui est celui où l’absence d’authentification se justifie le plus souvent par habitude, gouverner les comptes de service et agents autonomes et OIDC pour sécuriser les identifiants CI/CD montrent qu’une identité vérifiable existe aussi pour un programme.

Ce qu’une équipe en fait

Section intitulée « Ce qu’une équipe en fait »

Inventorier les chemins, pas les pages. La question utile n’est pas « cette fonction est-elle protégée ? » mais « par combien de chemins peut-on l’atteindre ? ». Les API internes, les ports de gestion, les interfaces de diagnostic et les files de messages comptent comme des chemins.

Refuser l’argument du réseau de confiance. Un service qui n’exige pas d’identité parce qu’il « n’est pas exposé » le devient tôt ou tard, par une erreur de configuration ou un rebond applicatif. L’authentification des services entre eux est un coût fixe, payé une fois, qui supprime cette dépendance à la topologie.

Traiter la consommation de ressources comme un critère de criticité, puisque le catalogue le fait : une opération coûteuse ouverte à l’anonyme est un défaut, même sans donnée en jeu.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Une organisation qui vérifie ses interfaces principales et ignore ses chemins secondaires obtient un audit rassurant et une exposition intacte. Le défaut se découvre alors de l’extérieur : un moteur de recherche spécialisé indexe les services qui répondent sans identité, et il est consulté plus souvent par ceux qui cherchent une porte que par ceux qui en possèdent une. Le coût est double. D’abord l’accès lui-même, qui n’exige aucune compétence : il n’y a pas d’attaque, seulement une requête. Ensuite l’impossibilité d’enquêter : un service sans authentification n’a généralement pas de journal d’accès nominatif, donc personne ne peut dire qui est venu, quand, ni ce qui a été consulté. La réponse à incident se résume à constater qu’on ne sait pas, ce qui est la pire réponse à fournir à une autorité de contrôle comme à un client.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Avant d’autoriser une action sensible, un système devrait savoir à qui il parle. Cette vérification s’appelle l’authentification : mot de passe, code à usage unique, clé de sécurité.

Le défaut décrit ici consiste à ne pas la demander du tout sur une fonction qui l’exigerait : une page d’administration, une interface de configuration d’appareil, une base de données, un tableau de bord technique. Il ne s’agit pas d’un mot de passe faible ou mal vérifié : il n’y a pas de mot de passe.

Ce défaut s’appelle CWE-306 dans le catalogue CWE. Il survit aux contrôles pour une raison précise, qui porte même un numéro à part : la fonction est généralement bien protégée par la voie principale, et accessible par une autre voie que personne n’a inventoriée (une interface technique, un port de maintenance, une adresse interne devenue joignable après une modification de réseau).

Deux idées méritent d’être retenues. D’abord, l’argument « ce service n’est pas accessible depuis Internet » n’est pas une protection mais un pari sur la configuration du réseau, qui change sans qu’on en informe les équipes. Ensuite, le catalogue considère comme critique toute fonction qui consomme beaucoup de ressources, même si elle ne révèle aucune donnée : un export volumineux ou un calcul lourd offert à des inconnus permet d’arrêter le service en le sollicitant, ce qui est une panne que l’on n’a pas choisie.

Enfin, une conséquence passe souvent inaperçue : un service qui ne demande aucune identité ne tient généralement aucun registre nominatif de ses visiteurs. Après coup, il est donc impossible de savoir qui est entré et ce qui a été consulté : ce qui transforme un incident technique en incertitude durable.

À lire aussi

Pages voisines

La citent

CWE-306 : authentification manquante sur une fonction critique

Elle cite

: les deux pages se citent l’une l’autre.