Trois niveaux d'information
Les termes décrivent ce que le client transmet au pentester avant les tests. Ils ne décrivent pas la qualité du test ni sa durée. Un même périmètre peut être testé dans les trois modes, avec des résultats différents.
Boîte noire
Le pentester part d'un nom de domaine ou d'une plage d'adresses. Il cartographie lui-même les services exposés, les sous-domaines et les applications. Cette approche mesure ce qu'un attaquant externe peut découvrir et exploiter sans aucun accès.
Boîte grise
Le pentester reçoit des comptes de test, idéalement deux par rôle (deux clients, deux administrateurs de tenant, un opérateur) pour vérifier que chacun reste dans son périmètre. Il peut aussi recevoir la documentation de l'API. C'est l'approche qui permet de trouver les failles IDOR et les élévations de privilèges.
Boîte blanche
Le pentester dispose en plus du code source, des schémas d'architecture et de la configuration. Il s'en sert pour repérer les chemins fragiles puis les exploite sur l'application en fonctionnement.
Comparatif
| Critère | Boîte noire | Boîte grise | Boîte blanche |
|---|---|---|---|
| Ce que reçoit le pentester | Un nom de domaine ou une plage d’adresses, rien d’autre. | Des comptes de test par rôle, l’URL de l’environnement, parfois une documentation API. | Code source, schémas d’architecture, comptes administrateur, configuration. |
| Menace simulée | Attaquant externe qui découvre la cible. | Client, partenaire ou compte compromis. | Attaquant très informé, ou revue exhaustive avant une échéance. |
| Ce qu’elle trouve bien | Services oubliés, préproductions exposées, failles sans authentification. | Contrôles d’accès, IDOR, élévation de privilèges, logique métier. | Défauts de conception, secrets dans le code, chemins peu visibles de l’extérieur. |
| Limite principale | Tout ce qui est derrière l’authentification reste peu ou pas testé. | Dépend de la qualité des comptes et des rôles fournis. | Plus de préparation côté client, et un temps d’analyse plus long. |
Choisir selon l'objectif
- Répondre à un questionnaire client ou à un assureur : boîte grise sur l'application principale. C'est là que l'acheteur attend des preuves sur les contrôles d'accès et l'isolation des données.
- Savoir ce qui est visible depuis Internet : boîte noire sur le périmètre externe. Utile après une acquisition, un changement d'hébergeur ou quand l'inventaire des actifs est incertain.
- Application critique ou régulée (paiement, santé, finance) : boîte grise complétée par un accès au code sur les fonctions sensibles. Voir notre article sur les tests sous DORA.
- Réseau interne : la question porte plutôt sur le point de départ du test. Voir pentest interne ou externe.
Effet sur le budget
Le prix d'un test d'intrusion dépend surtout du nombre de jours. Le mode choisi change la manière dont ces jours sont utilisés. En boîte noire, la reconnaissance consomme une partie du temps. En boîte grise, ce temps va aux tests des fonctions et des rôles. La boîte blanche ajoute du temps de lecture du code, qu'il faut prévoir dans le devis.
Ce qu'il faut préparer pour une boîte grise
- Deux comptes par rôle, avec des données fictives, dans au moins deux tenants si l'application est multi-client.
- L'URL de l'environnement testé et la confirmation qu'il est représentatif de la production.
- La documentation de l'API (fichier OpenAPI si disponible) et la liste des fonctions sensibles : paiement, export, gestion des droits.
- Un contact technique joignable pendant les tests et les fenêtres d'intervention autorisées.
Le déroulement d'un pentest décrit la suite, du cadrage au contre-test.
Questions fréquentes
Quelle approche est la plus réaliste ?
La boîte noire reproduit la position d'un attaquant qui ne connaît rien de la cible. La boîte grise reproduit celle d'un client, d'un partenaire ou d'un compte volé, ce qui correspond à une grande partie des incidents applicatifs. Les deux sont réalistes, pour des menaces différentes.
Un pentest en boîte noire coûte-t-il plus cher ?
À durée égale, le prix est le même. La différence porte sur l'usage du temps : en boîte noire, une partie des jours sert à découvrir ce que le client aurait pu fournir (comptes, documentation, liste des fonctions). Il reste donc moins de temps pour tester en profondeur.
Peut-on combiner plusieurs approches ?
Oui, c'est fréquent : une phase courte en boîte noire sur la surface exposée, puis des tests en boîte grise avec des comptes par rôle sur l'application. Le rapport doit indiquer quelle approche a été utilisée pour chaque partie du périmètre.
Un pentest en boîte blanche est-il un audit de code ?
Pas exactement. En boîte blanche, le pentester a accès au code et à l'architecture, mais il continue d'exploiter les failles sur l'application en fonctionnement. Un audit de code revoit le code source sans forcément démontrer l'exploitation. Les deux se complètent.
Références : OWASP Web Security Testing Guide ; Penetration Testing Execution Standard (PTES).