Pentest black box, grey box, white box : quelle boîte pour
quel objectif

Entre un test en boîte noire et un test en boîte blanche, une seule chose change : la quantité d'informations qu'on remet au pentester avant qu'il commence. Zéro pour la boîte noire, une URL et parfois juste un nom de domaine. Tout pour la boîte blanche, code source et accès compris. La boîte grise tient le milieu, quelques comptes et un peu de documentation. Même cible, même objectif, celui d'entrer, mais trois façons très différentes de s'y prendre.

Les devis empilent les anglicismes (black box, grey box, white box) sans toujours dire ce qu'ils changent à la mission, au budget, et surtout aux failles que vous allez trouver ou rater. Voyons les trois modes, leur logique, et lequel choisir selon ce que vous cherchez à prouver.

La métaphore de la boîte : ce qu'on met dedans

Le mot « boîte » vient de là : on regarde le système à tester comme une boîte, et la couleur dit à quel point elle est transparente. Boîte noire, vous ne voyez que l'extérieur. Boîte blanche, la paroi est en verre et vous voyez tout le mécanisme interne. Boîte grise, vous avez percé quelques trous pour glisser un regard à l'intérieur. La couleur décrit donc la connaissance préalable du testeur, rien d'autre.

Retenez ce curseur, tout le reste en découle. Plus la boîte est transparente, moins le testeur perd de temps à deviner, et plus il peut aller creuser en profondeur. Mais moins le test ressemble à ce que vivrait un vrai attaquant, qui, lui, part rarement avec les plans du bâtiment. Réalisme et couverture tirent dans des directions opposées, et le choix du mode, c'est le choix de l'endroit où vous placez le curseur.

Les 3 types de test d'intrusion, en clair

Voici les trois modes, du plus opaque au plus transparent, avec ce que chacun voit et ce qu'il permet de trouver.

• Black box (boîte noire) : zéro connaissance préalable. Le pentester attaque depuis l'extérieur, avec les mêmes informations qu'un pirate lambda qui tombe sur votre application. C'est le mode le plus réaliste quant au point de départ, mais sa couverture est plafonnée par le temps : chaque heure passée à cartographier la cible est une heure non passée à exploiter.
• Grey box (boîte grise) : connaissance partielle. On fournit généralement des comptes utilisateurs (un ou plusieurs rôles), parfois une documentation d'API ou un schéma d'architecture. Le testeur saute l'étape de reconnaissance à l'aveugle et consacre son temps à ce qui compte : la logique applicative, les contrôles d'accès entre rôles, les zones authentifiées. C'est le meilleur ratio réalisme/couverture pour du web, et de loin le mode le plus courant en pratique.
• White box (boîte blanche) : accès complet. Code source, architecture, comptes de tous les rôles, souvent les configs et la CI. La couverture est maximale : le testeur lit le code, remonte une entrée utilisateur jusqu'à la requête SQL, repère les failles qu'un attaquant externe mettrait des mois à deviner. C'est le mode d'un véritable audit de code, le plus exhaustif, mais aussi le plus exigeant en expertise et en temps.

Réalisme, couverture, coût : le vrai arbitrage

Toute la décision se joue sur trois axes qui ne bougent pas dans le même sens. Le réalisme (à quel point le test imite un vrai attaquant), la couverture (quelle proportion de la surface et de la logique on arrive à éprouver), et le coût en temps et en argent. Le tableau ci-dessous résume comment chaque mode se positionne.

  +--------------+-------------+--------------+-------------+
  |              | BLACK BOX   | GREY BOX     | WHITE BOX   |
  +--------------+-------------+--------------+-------------+
  | Infos data   | aucune      | comptes +    | code source |
  |              |             | doc partielle| + archi     |
  +--------------+-------------+--------------+-------------+
  | Realisme     | eleve       | bon          | faible      |
  | (attaquant)  |             |              |             |
  +--------------+-------------+--------------+-------------+
  | Couverture   | limitee     | tres bonne   | maximale    |
  +--------------+-------------+--------------+-------------+
  | Cout / temps | modere      | modere       | eleve       |
  +--------------+-------------+--------------+-------------+
  | Ideal pour   | exposition  | appli web    | audit de    |
  |              | externe     | metier       | code, SaaS  |
  +--------------+-------------+--------------+-------------+

Lisez ce tableau en diagonale et le profil de la boîte grise ressort : le black box est plus réaliste, le white box couvre davantage, mais le grey box reste correct sur chaque axe sans dominer aucun. C'est ce qui le fait dominer sur le web : la plupart des vulnérabilités applicatives graves (contrôles d'accès cassés, élévation de privilèges, logique métier contournée) vivent derrière l'authentification. Sans compte, le testeur reste sur le paillasson ; avec un compte, il entre dans la maison, là où se cachent les vrais problèmes.

Quand choisir la boîte noire

Le black box répond à une question bien précise : « qu'est-ce qu'un attaquant qui ne sait rien de nous peut faire depuis Internet ? » C'est le bon mode pour éprouver votre exposition externe, valider qu'une nouvelle mise en ligne ne laisse pas de porte ouverte évidente, ou rassurer une direction sur le scénario du pirate opportuniste. Notre pentest web blackbox se place exactement là : on part de zéro, comme l'adversaire.

Son défaut est structurel : le temps. Une bonne partie de la mission passe en reconnaissance (cartographier les sous-domaines, deviner les rôles, tester des identifiants), et ce temps ne produit pas de failles, il les prépare. Sur un périmètre riche et authentifié, un black box seul risque de rater des vulnérabilités profondes simplement parce que le testeur n'a jamais réussi à obtenir un compte pour aller voir derrière. Réaliste, oui ; exhaustif, non.

Quand la boîte grise est le bon défaut

Pour une application web métier, un SaaS, un espace client, le grey box est presque toujours le choix par défaut, et c'est un choix qu'on assume franchement. En fournissant un ou deux comptes par rôle, vous transformez la reconnaissance à l'aveugle en test dirigé. Le pentester passe directement aux questions qui font mal : est-ce qu'un utilisateur standard peut lire les données d'un autre ? forcer un rôle admin ? contourner le tunnel de paiement ? Ce sont les failles qui coûtent cher en vrai, et elles sont toutes derrière le login.

Quand la boîte blanche s'impose

Le white box brille quand votre objectif est l'exhaustivité. Application qui manipule des données sensibles, brique critique avant une mise en production majeure, exigence d'un client grand compte, contexte réglementaire : là, vous voulez la couverture maximale, pas le scénario le plus réaliste. En donnant le code source et les accès, le testeur remonte les flux de données à la source, repère les injections là où elles naissent, et débusque des failles qu'un test externe n'atteindrait jamais dans le temps imparti. C'est l'angle de notre pentest web whitebox, qui combine l'audit de code et l'exploitation dynamique.

La contrepartie : ça demande plus d'expertise (lire du code offensivement n'est pas donné à tout le monde) et donc un TJM plus élevé, ce qu'on détaille dans le prix d'un test d'intrusion. Vous payez la profondeur. Mais pour une appli où une faille passée inaperçue coûterait bien plus que la mission, c'est de loin le mode le plus rentable.

Comment on choisit, concrètement

Tout part de ce que vous voulez prouver. Si vous voulez mesurer votre exposition face à un inconnu, black box. Si vous voulez éprouver en profondeur une application avec des comptes et des rôles, grey box, et c'est le cas le plus fréquent. Si vous voulez la couverture la plus complète possible, code compris, white box. Rien n'empêche non plus de combiner : commencer en black box pour capturer le point de vue externe, puis basculer en grey ou white box pour la profondeur. C'est d'ailleurs ce qui se passe dans la plupart des missions sérieuses, et le déroulement d'un pentest montre comment ces phases s'enchaînent.

Un dernier repère utile : le mode de la boîte décrit la connaissance donnée au testeur, il ne dit rien de la nature de l'exercice. Un black box reste un pentest, c'est-à-dire l'exhaustivité sur un périmètre défini, et pas une simulation d'attaque à l'échelle de toute l'organisation. Si cette distinction vous intéresse, on l'a creusée dans red team ou test d'intrusion. Pour aller plus loin sur les standards de test, l'OWASP Web Security Testing Guide formalise ce que devrait couvrir une mission web quel que soit le mode choisi.

À retenir

• La couleur de la boîte décrit une seule chose : la quantité d'informations remise au pentester avant qu'il commence.
• Black box (zéro info) maximise le réalisme du point de départ, mais sa couverture est bridée par le temps de reconnaissance.
• Grey box (comptes fournis) offre le meilleur ratio réalisme/couverture pour le web, c'est le mode le plus courant en pratique.
• White box (code source et accès complets) donne la couverture maximale, idéal pour un audit de code, contre un TJM plus élevé.
• On ne choisit pas « le meilleur mode », on choisit celui qui répond à la question qu'on se pose. Et un simple compte de test change souvent tout.

Vous ne savez pas quelle boîte cocher pour votre application ? C'est normal, et c'est aussi notre travail de vous le dire. Parlez-nous de votre contexte et de ce que vous cherchez à prouver : on vous oriente vers un pentest web blackbox ou whitebox selon la profondeur qui sert votre objectif, sans vous vendre du temps que vous n'avez pas besoin de payer.