À quoi ressemble notre rapport d'évaluation
Un extrait illustratif et expurgé du livrable que vous recevez à l'issue d'une mission. Chaque constat ci-dessous est synthétique et porte sur une cible fictive. Aucune donnée client réelle n'y figure.
- Mission
- Test d'intrusion d'application web et d'API
- Cible
- Acme Cloud Platform (illustratif)
- Fenêtre d'évaluation
- Une mission de deux semaines (durée relative, sans dates fixes)
- Classification
- Confidentiel (exemple illustratif)
- Version du rapport
- Exemple v1.0
Synthèse à l'attention de la direction
Vexaro a évalué l'application web accessible depuis l'extérieur et l'API qui la sous-tend de l'Acme Cloud Platform au cours d'une mission grey-box de deux semaines. Les tests ont suivi l'OWASP Web Security Testing Guide et ont été vérifiés manuellement, au-delà de l'outillage automatisé.
Posture de risque globale : élevée. L'application applique correctement l'authentification et la sécurité du transport, mais l'autorisation au niveau des objets est appliquée de manière incohérente. Deux constats sont exploitables individuellement : une référence directe à un objet non sécurisée (IDOR) sur l'API de facturation et une falsification de requête côté serveur (SSRF) dans la fonction d'import de documents. Enchaînés, ils permettraient à un utilisateur authentifié peu privilégié de lire les factures d'autres locataires et d'atteindre les métadonnées internes du cloud. Renforcer la couche de contrôle d'accès et restreindre les requêtes sortantes traite l'essentiel du risque résiduel.
8 constats notés avec CVSS 3.1
Périmètre et méthodologie
La mission couvrait l'application web en production, son API REST, le compte cloud qui les héberge et le périmètre réseau accessible depuis l'extérieur. Les tests ont été limités dans le temps et menés depuis un compte authentifié peu privilégié ainsi que depuis une base non authentifiée.
- Application web : app.acme.example (parcours authentifiés et anonymes)
- API REST : api.acme.example (endpoints v1 et v2)
- Compte cloud : stockage objet, métadonnées de calcul et revue IAM
- Périmètre réseau externe : services exposés et configuration TLS
- Déni de service et tests de charge volumétrique
- Ingénierie sociale et accès physique
- SaaS tiers non exploité par la cible
Méthodologie et références
Les tests ont été menés en priorité manuellement et mis en correspondance avec des référentiels reconnus du secteur, afin que les constats soient reproductibles et la couverture auditable.
Web Security Testing Guide : les cas de test qui guident la couverture de l'application.
Application Security Verification Standard : la base de vérification au niveau des contrôles.
Tactiques et techniques des adversaires utilisées pour cadrer des chemins d'attaque réalistes.
Penetration Testing Execution Standard : le déroulé global de la mission.
Chaque constat est noté avec CVSS 3.1 et traduit en une cote de risque métier. La sévérité reflète l'exploitabilité et l'impact dans le contexte de cet environnement, et non le score de base seul.
Constats
Huit constats représentatifs de la mission, classés par sévérité. Le premier est développé en détail ci-dessous afin de montrer le niveau de détail de chaque entrée du rapport.
| ID | Constat | Sévérité | CVSS | Statut |
|---|---|---|---|---|
| ACME-2024-001 | IDOR sur l'API de facturation exposant les factures d'autres locataires | Élevée | 8.1 | Ouvert |
| ACME-2024-002 | Server-side request forgery dans l'import de documents | Élevée | 7.7 | Ouvert |
| ACME-2024-003 | Autorisation au niveau des fonctions rompue sur les endpoints d'administration | Moyenne | 6.5 | Corrigé et recontrôlé |
| ACME-2024-004 | Stored XSS dans le champ objet du ticket de support | Moyenne | 5.4 | Ouvert |
| ACME-2024-005 | Politique de mots de passe faible autorisant des identifiants triviaux | Faible | 3.7 | Ouvert |
| ACME-2024-006 | Des erreurs d'API verbeuses divulguent des traces de pile et des versions de bibliothèques | Faible | 3.1 | Risque accepté |
| ACME-2024-007 | En-têtes de sécurité manquants (HSTS, CSP, frame-ancestors) | Info | 2.4 | Corrigé et recontrôlé |
| ACME-2024-008 | Cookie de session émis sans l'attribut Secure | Info | 2.0 | Ouvert |
Exemple de constat en détail complet
Un constat, développé avec la profondeur que reçoit chaque entrée d'un rapport réel : description, impact, preuve, reproduction, remédiation et références.
IDOR sur l'API de facturation exposant les factures d'autres locataires
- ID du constat
- ACME-2024-001
- CVSS 3.1
- 8.1 (Élevée)
- Vecteur
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- CWE
- CWE-639 : Authorization Bypass Through User-Controlled Key
Description
L'API de facturation renvoie les documents de facture à partir d'un identifiant numérique séquentiel fourni dans le chemin de la requête. L'endpoint authentifie l'appelant mais ne vérifie jamais que la facture demandée appartient au locataire de l'appelant. Tout utilisateur authentifié peut donc énumérer l'identifiant et récupérer des factures appartenant à d'autres organisations, y compris les noms des contacts de facturation, les montants et les lignes de détail.
Impact
Il s'agit d'une atteinte à la confidentialité entre locataires. Un utilisateur authentifié peu privilégié de n'importe quel locataire peut lire les données financières de tous les autres locataires en incrémentant un seul entier. Les données exposées comprennent des conditions commerciales et des coordonnées personnelles, créant à la fois une exposition liée à la vie privée et au renseignement concurrentiel. Comme les identifiants sont séquentiels, l'ensemble du corpus de factures peut être extrait de façon programmatique en quelques minutes.
Preuve
Requête et réponse illustratives. L'hôte, le token et les valeurs sont synthétiques et expurgés.
GET /v2/invoices/10428 HTTP/1.1
Host: api.acme.example
Authorization: Bearer eyJhbGciOi...REDACTED.SAMPLE.TOKEN
Accept: application/jsonHTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 10428,
"tenant_id": 3304,
"bill_to": "[REDACTED], Northwind Trading",
"amount_due": "14,920.00 USD",
"status": "unpaid"
}'Étapes de reproduction
- 1Authentifiez-vous sur l'application avec un compte valide peu privilégié et capturez le token bearer.
- 2Demandez votre propre facture, p. ex. GET /v2/invoices/10427, et confirmez une réponse 200.
- 3Décrémentez ou incrémentez l'identifiant numérique (.../10428, .../10429) et rejouez la requête avec votre propre token.
- 4Constatez que des factures associées à d'autres valeurs de tenant_id sont renvoyées, ce qui confirme l'absence de contrôle d'autorisation au niveau de l'objet.
Remédiation
Imposez un contrôle d'autorisation au niveau de l'objet à chaque requête : résolvez la facture, puis vérifiez que son tenant_id correspond à celui du principal authentifié avant de renvoyer la moindre donnée, sinon répondez 404. Appliquez le contrôle de façon centralisée (par exemple dans une couche de politique ou un périmètre de requête) plutôt que par handler, et ajoutez un test de non-régression qui vérifie qu'une requête inter-locataires est rejetée. Remplacer les identifiants séquentiels par des identifiants non devinables réduit l'énumération, mais relève de la défense en profondeur et ne remplace pas le contrôle d'autorisation.