Glossaire de sécurité

Boîte noire face à boîte grise face à boîte blanche

Ces trois termes décrivent ce que le testeur sait de la cible avant de commencer et, par conséquent, jusqu'où il peut réellement aller dans le temps disponible. Ce sont des degrés de connaissance, et non un classement de qualité.

Boîte noire : le point de vue de l'extérieur

Dans un test en boîte noire, le testeur démarre avec peu ou pas de connaissance interne, souvent juste un domaine ou une plage d'adresses IP, et agit comme un attaquant externe. C'est réaliste pour modéliser un acteur extérieur opportuniste. Mais le temps limité est consacré à une découverte qu'un véritable attaquant pourrait mener pendant des mois, si bien que des failles réelles mais plus profondes peuvent passer inaperçues par simple manque de temps.

Boîte grise : la norme la plus rentable

La boîte grise donne au testeur une connaissance partielle, généralement des comptes valides pour différents rôles et une spécification d'API telle qu'OpenAPI/Swagger. C'est le choix pragmatique par défaut pour la plupart des travaux sur applications et API, car le budget sert à trouver de vraies failles plutôt qu'à la reconnaissance. Les failles d'autorisation telles que BOLA/IDOR ne peuvent être trouvées qu'avec plusieurs comptes : avec un seul jeton, ou aucun, il est impossible de les éprouver.

Boîte blanche : assurance maximale

Le test en boîte blanche (ou boîte de cristal, crystal-box) donne une information complète : code source, architecture, configuration et accès aux personnes concernées. Il permet la couverture la plus profonde et constitue le bon choix lorsque vous avez besoin d'une assurance élevée ou que vous vérifiez la conformité aux niveaux supérieurs d'un standard. OWASP ASVS 5.0 indique que ses niveaux les plus rigoureux peuvent exiger précisément ce type d'accès à la documentation, au code source et à la configuration.

Laquelle choisir ?

Choisissez selon l'objectif d'assurance, et non selon l'option qui paraît la plus difficile. La boîte noire convient à une simulation réaliste d'attaquant externe, la boîte grise est le choix par défaut efficace pour les évaluations web et API, et la boîte blanche est destinée aux revues à haute assurance et à la vérification de conformité aux standards. Une idée reçue est désormais dépassée : ASVS 5.0 a redéfini le niveau 1, si bien que l'ancien raccourci « ASVS L1 équivaut à un test d'intrusion en boîte noire » ne tient plus. Le niveau de vérification est désormais une décision fondée sur le risque.

Questions fréquentes

Ils décrivent ce que le testeur sait de la cible avant de commencer, pas un classement de qualité. La boîte noire part avec peu ou pas de connaissance interne ; la boîte grise apporte une connaissance partielle, comme des comptes valides et une spécification ; la boîte blanche donne accès au code source, à l'architecture et à la configuration complets.

La boîte grise est le choix pragmatique par défaut pour la plupart des tests d'applications et d'API, car le budget sert à trouver de vraies failles plutôt qu'à la reconnaissance. C'est particulièrement important pour les failles d'autorisation comme BOLA/IDOR, que l'on ne trouve qu'avec plusieurs comptes dans différents rôles : un seul jeton, ou aucun, ne permet pas de les éprouver.

Non. OWASP ASVS 5.0 a redéfini le niveau 1 : l'ancien raccourci « ASVS N1 = test d'intrusion en boîte noire » ne tient plus. Le niveau de vérification relève désormais d'une décision de risque, et les niveaux ASVS supérieurs, plus rigoureux, peuvent exiger un accès de type boîte blanche au code source et à la configuration.

Parlez à un vrai praticien.

Une question à laquelle ces pages n'ont pas répondu ? Dites-nous ce que vous cherchez à protéger et nous vous orienterons vers la mission adaptée. La première consultation est gratuite.