Comparatif
Test en boîte noire ou boîte grise : quelle différence et lequel choisir ?
En résumé
En boîte noire, l’analyste part sans information, comme un attaquant externe ; en boîte grise, il reçoit des comptes de test et de la documentation. À budget égal, la boîte grise trouve nettement plus de failles, parce que le temps n’est pas dépensé à deviner ce qu’on pourrait simplement lui dire, et que le contrôle d’accès exige des comptes. La boîte noire sert à une autre question : que voit et que peut un inconnu depuis Internet. Pour une application, choisissez la boîte grise par défaut.
Sommaire : 5 sections
Ce que chaque option fait, et ce qu’elle ne fait pas
Un attaquant sans information, vu depuis l’extérieur.
Boîte noire
L’analyste ne reçoit que le nom de la cible. Il doit découvrir la surface, les technologies et les parcours par lui-même. Elle répond à « que voit et que peut un inconnu depuis Internet ? ».
- Prix
- À partir de 1 490 € pour une application web, mais avec une couverture réduite à ce qui est visible sans compte. Le prix monte avec la taille de la surface exposée à découvrir.
- Durée
- 2 à 15 jours selon le périmètre
Ce que cela apporte
- Reproduit fidèlement la position d’un attaquant sans accès préalable.
- Révèle ce que vous exposez sans le savoir (sous-domaines oubliés, services ouverts).
- Peu de préparation côté client.
Ce que cela ne fait pas
- Une partie du temps part dans la découverte, pas dans la recherche de failles.
- Sans comptes, tout l’espace authentifié reste hors de portée : contrôle d’accès, rôles, multi-tenant.
- Résultats plus faibles par euro dépensé sur une application avec comptes.
- Peut donner une fausse impression de solidité si la surface publique est propre.
Comptes, rôles et documentation fournis dès le départ.
Boîte grise
L’analyste reçoit des comptes de test pour chaque rôle, une documentation d’architecture ou d’API, parfois un accès au code. Elle répond à « un utilisateur connecté peut-il aller au-delà de ce qui lui est permis ? ».
- Prix
- À partir de 1 490 € pour une application web, 1 290 € pour une API. Le prix monte avec le nombre de rôles et de parcours à tester.
- Durée
- 2 à 15 jours selon le périmètre
Ce que cela apporte
- Concentre le temps sur la recherche de failles, pas sur la devinette.
- Seule façon de tester le contrôle d’accès entre rôles et entre clients.
- Plus de failles trouvées pour le même budget sur une application avec comptes.
- Test plus reproductible, donc plus facile à re-tester après correction.
Ce que cela ne fait pas
- Demande de préparer des comptes de test et une documentation.
- Ne montre pas ce qu’un inconnu découvrirait sans aucune information.
- Un volume de rôles important augmente le périmètre et donc le prix.
Un verdict par ligne
La colonne de droite tranche. Quand les deux options se valent, elle le dit : c’est un résultat à part entière.
| Critère | Boîte noire | Boîte grise | Avantage |
|---|---|---|---|
| Question à laquelle on répond | Que peut un inconnu sans aucun accès ? | Que peut un utilisateur connecté, ou un compte compromis ? | égal |
| Résultats par euro dépensé sur une application | Faibles : le temps part dans la découverte. | Élevés : le temps est dédié à la recherche de failles. | Boîte grise |
| Contrôle d’accès et multi-tenant | Inaccessibles sans comptes. | Testés avec une identité par rôle et par organisation. | Boîte grise |
| Découverte de la surface exposée | Cœur de l’exercice. | Secondaire, car la surface est fournie. | Boîte noire |
| Réalisme du point de départ | Proche d’un attaquant externe sans accès. | Proche d’un compte client malveillant ou compromis. | égal |
| Préparation côté client | Minimale. | Comptes de test, documentation, référent technique. | Boîte noire |
| Reproductibilité et re-test | Moins stable, car dépend de ce que l’analyste découvre. | Stable, avec des scénarios documentés. | Boîte grise |
Lequel dans votre situation
Prenez boîte noire si…
- Vous voulez savoir ce qu’un inconnu découvre de votre organisation depuis Internet, sans application précise en tête.
- Vous avez des actifs oubliés ou mal inventoriés et souhaitez les faire apparaître.
- Votre périmètre est essentiellement public, sans espace authentifié.
Prenez boîte grise si…
- Votre application comporte des comptes, des rôles ou plusieurs clients sur la même plateforme.
- Vous voulez le meilleur rapport entre failles trouvées et budget.
- Vous exposez une API consommée par des clients ou des partenaires.
- Vous avez besoin d’un test facilement reproductible après correction.
Et si la réponse était « les deux » ?
Quand les deux questions se posent, une courte phase de reconnaissance en boîte noire sur la surface exposée précède un test en boîte grise sur l’application. La première révèle ce que vous ignoriez exposer ; la seconde consacre le budget principal à la profondeur, là où se trouvent les failles les plus coûteuses. Prévoir la boîte noire seule pour une application avec comptes est presque toujours un mauvais arbitrage.
Ce qu’on nous demande ensuite
Pourquoi la boîte grise trouve-t-elle plus de failles ?
Parce que le temps de l’analyste est dépensé à chercher des failles, pas à découvrir ce que vous pourriez lui dire. Les comptes de test ouvrent l’espace authentifié, où se trouvent le contrôle d’accès, les rôles et le cloisonnement entre clients, soit les défauts les plus coûteux. Sans comptes, ces défauts ne sont tout simplement pas testables.
La boîte noire est-elle inutile ?
Non, elle répond à une autre question : que découvre et que peut un attaquant sans aucun accès. Elle révèle des actifs oubliés, des services exposés et des fuites d’information. Elle est utile en reconnaissance ou sur un périmètre public, mais insuffisante pour tester une application avec comptes.
Que faut-il préparer pour une mission en boîte grise ?
Un compte de test par rôle (et deux organisations distinctes si la plateforme sert plusieurs clients), une documentation d’architecture ou d’API, un environnement stable où tester, et un référent technique joignable pendant la mission. Cette préparation prend généralement moins d’une journée et se rattrape largement sur la couverture obtenue.
Prestations concernées
- PrestationPentest webSavoir ce qu’un attaquant obtiendrait sur votre application.
- PrestationPentest APILes API portent les données et moins de garde-fous que les interfaces.
- PrestationAudit de codeRetrouver la ligne de code responsable et la raison pour laquelle elle a été écrite.
Autres arbitrages
- ComparatifScan ou pentest : le comparatifUn scan automatisé et un test d’intrusion portent des noms proches, mais ne répondent pas à la même question et ne coûtent pas le même prix. Critères, situations et erreur d’achat la plus fréquente.
- ComparatifInterne ou externe ?Faire tester par l’équipe qui a construit le système, ou par un tiers. Le biais de l’équipe constructrice, le coût réel d’un recrutement offensif, et les cas où une équipe interne suffit.
- ComparatifPentest interne ou externeUn test d’intrusion externe part d’Internet, un test interne part d’un poste ou d’un compte déjà dans le réseau. Ce que chacun révèle, son prix d’entrée et dans quel ordre les mener.
Réponse à toute demande sous 24 h ouvrées
Un périmètre à faire tester ?
Le cadrage est gratuit et sans engagement. Trente minutes suffisent à savoir si une mission est pertinente, laquelle, et ce qu’elle coûterait.
- Accord de confidentialité systématique
- Cadrage gratuit et sans engagement
- Périmètre et prix écrits avant le début