Pentest greybox 2026 : méthode, scope, findings clés

Un pentest greybox (ou grey box, test d'intrusion en boîte grise) est un test d'intrusion mené avec une connaissance partielle du système cible transmise par le commanditaire : deux à quatre comptes utilisateurs avec privilèges différents, documentation fonctionnelle ou spécification OpenAPI/Swagger, schéma d'architecture haut niveau, liste des technologies et versions, intégrations tierces identifiées. Il se positionne entre le black box (aucune information, simulation attaquant externe anonyme) et le white box (code source, credentials admin complets, schémas réseau détaillés, simulation auditeur interne) et simule typiquement un scénario assumed breach : un attaquant ayant déjà franchi le périmètre via phishing, credential stuffing ou compromission d'un partenaire, et cherchant à élever ses privilèges, se déplacer latéralement et exfiltrer des données sensibles. C'est le type de pentest le plus fréquent sur applications web et APIs en 2026 : 60 à 70 % des missions selon les observatoires Cobalt.io et Packetlabs, car il offre le meilleur ratio couverture / budget. Un greybox couvre 60 à 80 % des vulnérabilités exploitables (incluant les Broken Access Control, IDOR, BOLA/BFLA, failles de logique métier, escalations de privilèges) pour un budget typique de 8 000 à 35 000 € HT sur une application SaaS de taille moyenne. Cet article détaille la méthodologie greybox, les informations à transmettre au prestataire, les findings typiques qu'il détecte, les cas d'usage où le greybox est pertinent vs black/white box, et les budgets de référence 2026.

1. Positionnement du greybox dans le paysage pentest

Trois modèles coexistent depuis les années 2000, formalisés par PTES (Penetration Testing Execution Standard), OWASP WSTG (Web Security Testing Guide v4.2) et NIST SP 800-115.

2. Scénario « assumed breach » et profils d'attaquant

Le greybox simule l'hypothèse de travail la plus réaliste en 2026 : le périmètre sera franchi tôt ou tard via phishing (SANS « Initial Access Broker » report, 2024 : 83 % des ransomwares commencent par un phishing ou un credential stuffing), via compromission d'un sous-traitant (SolarWinds 2020, MOVEit 2023, 3CX 2023), via fuite de credentials sur le dark web (LinkedIn 2021, Twitter 2022, 23andMe 2023). La question n'est plus « est-ce qu'un attaquant entrera ? » mais « que peut-il faire une fois à l'intérieur ? ».

Quatre profils d'attaquant greybox standards :

Le profil doit être négocié explicitement dans les Rules of Engagement et reproduit dans le rapport (voir ressource rapport de pentest pour la structure contractuelle complète). PASSI v2.2 (référentiel ANSSI juin 2024) impose formellement cette négociation préalable.

3. Informations à transmettre au prestataire

Trop d'informations transforme le greybox en white box superficiel. Trop peu le transforme en black box déguisé. Le juste milieu 2026 se décompose en cinq blocs obligatoires à fournir dans les 48 h du kickoff.

3.1 Comptes de test

Au moins 4 comptes, idéalement 6, couvrant les combinaisons pertinentes :

• User standard A sur tenant/organisation 1.
• User standard B sur tenant/organisation 1 (même tenant qu'A, pour tester l'isolation intra-tenant).
• User standard C sur tenant/organisation 2 (tenant différent, pour tester l'isolation inter-tenants).
• User premium / role avancé sur tenant 1 (pour tester les fonctionnalités par rôle).
• Administrateur fonctionnel sur tenant 1 (pas super-admin, un admin de tenant).
• Super-admin (optionnel, seulement si la fonction existe et est dans le scope).

3.2 Documentation fonctionnelle

• Spécification OpenAPI 3.x (Swagger) pour les APIs REST.
• Schéma GraphQL introspection pour les APIs GraphQL.
• Documentation produit orientée utilisateur (ce que le user final voit).
• Liste des endpoints principaux et des workflows métier critiques.
• Matrice des rôles et permissions (RBAC, ABAC selon cas).

3.3 Architecture haut niveau

Un schéma logique (pas détaillé réseau) avec :

• Composants applicatifs majeurs.
• Flux de données entre composants.
• Zones de confiance (DMZ, LAN, services partenaires).
• Emplacement des secrets et données sensibles (hash password, PII, données financières, PHI).

3.4 Stack technique

Liste précise avec versions exactes :

• Frameworks applicatifs (Django 5.0, Laravel 11, Rails 7.1, Spring Boot 3.3, Next.js 14).
• Base de données et version (PostgreSQL 15.5, MySQL 8.0, MongoDB 7.0).
• Middleware (Redis, RabbitMQ, Kafka).
• CDN, WAF, load balancer.
• Runtime (Node.js 20, Python 3.12, Java 21, .NET 8).
• Hébergement (AWS, Azure, GCP, OVH, on-premise).

Cette information permet au testeur de cibler rapidement les CVE connues du stack (ex: CVE-2024-3094 xz-utils, CVE-2023-38545 curl, CVE-2021-44228 Log4Shell toujours trouvée en prod en 2025).

3.5 Intégrations tierces

• SSO (Azure AD / Entra ID, Okta, Google Workspace, Ping Identity).
• Paiement (Stripe, Adyen, PayPal, GoCardless).
• Messagerie (SendGrid, Mailgun, Postmark, SES).
• Stockage (S3, Azure Blob, GCS).
• Observability (Datadog, Sentry, LogRocket).
• Auth externe (Auth0, Clerk, Supabase Auth, Firebase Auth).

4. Méthodologie d'un pentest greybox

La méthodologie greybox suit PTES enrichi d'OWASP WSTG v4.2 pour le web, OWASP MASTG pour le mobile, OWASP API Security Top 10 2023 pour les APIs.

4.1 Phases détaillées

4.2 Focus par catégorie OWASP Top 10 Web 2021 en greybox

Certaines catégories sont particulièrement pertinentes en greybox car non détectables en black box.

4.3 Focus par catégorie OWASP API Security Top 10 2023 en greybox

Les APIs sont dominantes en 2026 (applications SaaS, mobile backends, intégrations B2B). OWASP API Security Top 10 2023 liste 10 catégories quasi toutes détectables uniquement en greybox.

5. Findings typiques d'un pentest greybox applicatif

5.1 Broken Access Control (A01:2021) et IDOR

Famille dominante des findings greybox. Deux patterns principaux :

IDOR direct : l'application expose un identifiant prédictible (ID numérique incrémenté, slug devinable) dans une URL ou un paramètre, et vérifie l'authentification mais pas l'autorisation.

# exemple-idor-bypass.py
# Exemple greybox : exploitation IDOR sur endpoint /api/v1/invoices/{id}
# Hypothese : user A authentifie, cherche a lire les factures du user B.
# Contexte legal : reproduction uniquement en scope autorise ecrit (Rules of Engagement).
 
import requests
 
base = "https://target.example.com"
# Token valide pour user A (compte de test fourni par le commanditaire)
headers_a = {"Authorization": "Bearer <TOKEN_USER_A>"}
 
# Premiere requete legitime : user A lit ses propres factures
r = requests.get(f"{base}/api/v1/invoices/42", headers=headers_a)
assert r.status_code == 200
 
# Tentative IDOR : user A tente de lire la facture d'un autre user (id 43)
r = requests.get(f"{base}/api/v1/invoices/43", headers=headers_a)
 
if r.status_code == 200 and "invoice" in r.json():
    print("IDOR confirme - user A peut lire la facture d'un autre user")
    # Enumeration complete pour cartographier l'ampleur
    for invoice_id in range(1, 1000):
        r = requests.get(f"{base}/api/v1/invoices/{invoice_id}", headers=headers_a)
        if r.status_code == 200:
            print(f"Facture {invoice_id} accessible - {r.json().get('customer_email')}")

Privilege escalation : manipulation d'un rôle, d'un flag ou d'une permission dans un payload PATCH/PUT pour s'élever. Pattern classique : l'API accepte un champ role ou is_admin qui devrait être filtré mais ne l'est pas côté serveur.

5.2 BOLA / BFLA (OWASP API Security)

BOLA (Broken Object Level Authorization) : identique à l'IDOR mais spécifiquement sur API. BFLA (Broken Function Level Authorization) : accès à une fonction normalement réservée (endpoint /admin/* accessible via un user standard).

5.3 Failles de logique métier

Catégorie que seul un testeur humain avec compréhension fonctionnelle peut détecter (aucun scanner ne les trouvera). Exemples typiques :

• Discount stacking : appliquer plusieurs coupons non cumulables en contournant la validation front.
• Quantité négative : commander -10 produits, recevoir un crédit, exploit connu depuis 20 ans mais encore fréquent.
• Race conditions : exploiter une fenêtre entre check et action pour doubler une ressource.
• Bypass paiement : manipuler la requête de confirmation pour valider sans charge effective.
• Workflow bypass : sauter des étapes d'un processus (ex: passer de « pending » à « approved » sans validation intermédiaire).

5.4 SSRF authentifié

SSRF (Server-Side Request Forgery) authentifié : une feature applicative (import depuis URL, preview de lien, webhook) permet de faire requester des URLs internes (169.254.169.254 AWS metadata, http://localhost:* services internes, services non exposés publiquement). OWASP #1 en API Top 10 2023.

5.5 Chaîne d'attaque type

Exemple de chaîne d'attaque realistic sur une application SaaS B2B :

1. Initial access : compte user standard compromis (phishing simulé).
2. IDOR sur /api/v1/organizations/{id}/users : cartographier les users d'autres organisations.
3. BOLA sur /api/v1/users/{id} : lire les profils incluant emails d'admin.
4. SSRF authentifié dans la feature « webhook test » : accès aux métadata AWS EC2.
5. Credential harvesting : extraction IAM role via metadata → aws sts assume-role.
6. Pivot : accès à d'autres services AWS du tenant.
7. Exfiltration : démonstration lecture S3 production.

Ce type de chaîne, impossible à reproduire en black box (pas d'accès initial), impossible à deviner en scan automatique (pas de signature), représente typiquement la « killer finding » d'un rapport greybox de qualité.

6. Avantages et limites du greybox

6.1 Avantages

• Meilleur ratio couverture / budget : 60-80 % de couverture à 40-50 % du prix d'un white box.
• Scénario réaliste 2026 : l'assumed breach correspond au modèle de menace dominant.
• Findings actionnables : IDOR, BAC, BOLA, logique métier sont des classes de bugs faciles à corriger une fois identifiées.
• Temps de setup court : kickoff en 1 journée, tests démarrent J+1.
• Transferable : les conclusions se répercutent directement sur les guidelines de développement sécurisé (SDL) de l'équipe.

6.2 Limites

• Ne couvre pas la couche code : vulnérabilités de code complexes (désérialisation custom, race conditions kernel, crypto custom mal implémentée) échappent sans code review.
• Ne valide pas la posture externe : le périmètre exposé anonyme reste à tester en complément.
• Dépend de la qualité des comptes fournis : si le commanditaire fournit des comptes trop similaires ou trop privilégiés, le greybox perd sa valeur.
• Faux négatifs sur infrastructure : les misconfigurations réseau (segmentation, firewall rules, VPN) sortent du scope greybox applicatif standard.

7. Cas d'usage 2026 : quand choisir greybox

8. Budget et durée 2026 en France

Fourchettes indicatives agrégées (Cobalt.io, Synacktiv, Synetis, HTTPCS, Ziwit, Wavestone, CGI).

Ajouts fréquents :

• Retest post-remédiation : +2-4 jours soit +3 000 à 7 000 €.
• Audit qualifié PASSI : +30 à +80 % sur le prix de base.
• Restitution orale en présentiel hors Île-de-France : +1 jour + frais de déplacement.
• Traduction du rapport en anglais : +15-25 %.

9. Comment négocier un greybox sérieux

Points de vigilance côté commanditaire pour éviter un greybox superficiel ou mal cadré :

1. Exiger une liste nominative des testeurs avec leurs certifications (OSCP, OSWE, CRTO, PNPT, CPTS) et années d'expérience.
2. Vérifier le scope détaillé dans la proposition : liste exhaustive des endpoints, hosts, scope OWASP Top 10 vs top 25 vs complet.
3. Fixer le nombre de jours-homme minimum, pas uniquement un montant forfaitaire. Un « pentest greybox à 3 000 € » sur 15 jours de calendrier ne produit jamais un rapport sérieux.
4. Exiger un rapport au format éditable (Word, Markdown) avant PDF final, pour corrections factuelles.
5. Inclure un retest de 2-4 jours contractuellement, facturé dès le départ.
6. Demander des références clients vérifiables dans le secteur.
7. Privilégier les prestataires PASSI ou certifiés CREST / ISO 17025 pour les contextes sensibles.

Pour approfondir les aspects contractuels du livrable, voir la ressource rapport de pentest qui détaille la structure du livrable, les exigences PASSI, la notation CVSS 4.0 et les pièges de rédaction. La ressource TJM pentester freelance documente les tarifs des profils indépendants, et étapes pour devenir pentester couvre le parcours d'accès au métier.

Points clés à retenir

• Greybox = connaissance partielle : comptes + doc fonctionnelle + architecture haut niveau + stack + intégrations.
• Scénario assumed breach : simulation d'un attaquant ayant déjà franchi le périmètre, aligné sur le modèle de menace 2026.
• Dominant en 2026 : 60-70 % des missions applicatives web et API.
• Couverture 60-80 % : meilleur ratio coverage/budget entre black et white box.
• Findings typiques : Broken Access Control (OWASP A01), IDOR, BOLA/BFLA (API1/API5), logique métier, SSRF authentifié, privilege escalation.
• Information à fournir en 48h : 4-6 comptes dans 2 tenants, OpenAPI, archi logique, versions stack, intégrations.
• Budget 2026 FR : 8 000 à 35 000 € HT selon scope. PASSI +30-80 %.
• Durée typique : 8-15 jours-homme sur app moyenne, dont 20-30 % rédaction rapport.
• Complémentaire : black box externe + greybox applicatif + white box sur composants sensibles = couverture quasi totale à coût optimisé.