Trois défauts de sécurité web, leurs preuves, les corrections et les cas de re-test.
Ce document montre un format de livrable. Toutes les observations sont fictives. Il ne correspond à aucune mission client.
Périmètre et lecture
Cible fictive : Portail Atelier · laboratoire fictif. Périmètre : Portail interne, console d’administration et module de commande.
Ces constats illustrent une exposition de données privées, une fonction privilégiée mal protégée et un montant de commande manipulable. Leur gravité dépendrait du contexte réel. Aucune note CVSS n’est attribuée : les hypothèses détaillées nécessaires à sa justification ne font pas partie de cet aperçu.
Un rapport précise le périmètre autorisé, les dates, les versions, les accès disponibles, la méthode et les limites de couverture. Les risques sont évalués selon leur impact métier et les conditions d’exploitation. Les re-tests réellement effectués sont distingués des corrections annoncées.
WEB-01 / Autorisation par ressource
Un salarié accède aux salaires de ses collègues.
Élevée dans ce scénario
Synthèse
Dans le portail d’une même entreprise, un salarié du service commercial peut ouvrir le fichier de paie réservé aux RH en changeant le numéro du document dans la requête. Être connecté ne lui donne pas ce droit.
Impact illustré : Confidentialité : les noms et salaires des collègues deviennent accessibles à une personne qui n’est pas habilitée à les consulter.
Technique illustrée
IDOR · Accès direct à un document non autorisé
Modifier l’identifiant du document dans une requête authentifiée, puis vérifier les droits sur la ressource retournée.
Conditions et preuve
Laboratoire fictif, comptes dédiés et données de démonstration. Aucune cible réelle ni donnée personnelle.
Se connecter avec le compte de démonstration d’un salarié du service commercial.
Remplacer le numéro d’un document commercial autorisé par celui du fichier de paie réservé aux RH.
Constater que le serveur retourne les salaires alors que ce compte n’a aucun droit RH.
GET /api/documents/204
200 OK · fichier de paie divulgué
Correction recommandée
Vérifier côté serveur que le compte dispose du droit de lecture sur ce document précis. L’accès au portail et l’appartenance à la même entreprise ne suffisent pas.
Contrôle des droits sur chaque document demandé, et pas seulement de la connexion.
Refus sans contenu ni métadonnée RH pour les comptes non habilités.
Tests de régression avec un compte RH, un commercial et un compte sans session.
Re-test illustré
GET /api/documents/204
403 Forbidden · document RH protégé
Cas vérifiés après correction
Cas testé
Résultat attendu
Compte RH habilité
200 · autorisé
Salarié commercial
403 · refusé
Compte sans session
401 · refusé
Ces résultats illustrent le re-test attendu. Ils ne correspondent pas à des tests réalisés chez un client.
Limites : l’exemple porte sur une fonction ciblée et ne prouve pas la sécurité de l’ensemble d’une application. Dans une mission, les accès, versions et cas vérifiés seraient consignés.
WEB-02 / Autorisation par fonction
Un bouton caché ne protège pas un export.
Élevée dans ce scénario
Synthèse
Le bouton d’export des comptes est masqué pour les utilisateurs standards. Pourtant, l’API exécute leur demande d’export, car elle ne vérifie pas le rôle du compte.
Impact illustré : Confidentialité : export de données de comptes depuis une fonction d’administration.
Technique illustrée
BFLA · Fonction accessible au mauvais rôle
Appeler directement une fonction d’administration avec un compte standard, même lorsque son bouton est masqué.
Conditions et preuve
Laboratoire fictif, comptes dédiés et données de démonstration. Aucune cible réelle ni donnée personnelle.
Se connecter avec un compte disposant uniquement du rôle standard.
Appeler directement l’endpoint d’export de la console d’administration.
Constater que masquer le bouton n’empêche pas l’API de retourner les données.
GET /api/admin/users/export
200 OK · export accessible
Correction recommandée
Centraliser les autorisations côté serveur et exiger le droit d’export sur l’endpoint d’administration.
Refus par défaut pour les fonctions privilégiées.
Contrôle du rôle et du droit spécifique avant d’exécuter l’export.
Tests des endpoints d’administration pour chaque niveau de privilège.
Re-test illustré
GET /api/admin/users/export
403 Forbidden · rôle insuffisant
Cas vérifiés après correction
Cas testé
Résultat attendu
Administrateur autorisé
200 · autorisé
Utilisateur standard
403 · refusé
Session absente ou expirée
401 · refusé
Le périmètre du re-test réel dépend des accès fournis et des corrections disponibles. Les limites sont consignées dans le rapport.
Limites : l’exemple porte sur une fonction ciblée et ne prouve pas la sécurité de l’ensemble d’une application. Dans une mission, les accès, versions et cas vérifiés seraient consignés.
WEB-03 / Logique métier
Le prix du panier ne se décide pas dans le navigateur.
Élevée dans ce scénario
Synthèse
Un article coûte 120 € au catalogue. Le navigateur envoie le montant de la commande et le serveur lui fait confiance : un acheteur peut le remplacer par 1 € et créer une commande à ce prix.
Impact illustré : Intégrité commerciale : une commande est enregistrée avec un montant non autorisé. Cet exemple s’arrête avant tout paiement réel.
Technique illustrée
Parameter tampering · Manipulation du prix
Modifier le montant envoyé par le navigateur pour vérifier si le serveur le reprend ou le recalcule depuis son catalogue.
Conditions et preuve
Laboratoire fictif, comptes dédiés et données de démonstration. Aucune cible réelle ni donnée personnelle.
Ajouter au panier l’article fictif affiché à 120 €.
Modifier le prix transmis par le navigateur à 1 €, sans changer le produit ni la quantité.
Observer la commande créée à 1 € : le serveur a utilisé une valeur fournie par le client.
POST /api/orders
{ "productId": "AT-120", "quantity": 1, "unitPrice": 1 }
201 Created · commande à 1 €
Correction recommandée
Calculer le total côté serveur depuis le catalogue et les remises autorisées. Les montants transmis par le navigateur ne constituent jamais la référence du prix.
Catalogue et règles de remise comme source des prix côté serveur.
Validation des quantités et des remises applicables au compte.
Montant cohérent entre commande et demande de paiement.
Re-test illustré
POST /api/orders
{ "productId": "AT-120", "quantity": 1, "unitPrice": 1 }
201 Created · prix recalculé à 120 €
Cas vérifiés après correction
Cas testé
Résultat attendu
Prix navigateur modifié à 1 €
120 € · recalculé
Quantité négative
422 · refusée
Remise autorisée de 10 %
108 € · calculé
Montants et article fictifs. Les règles de TVA, de remise et de paiement d’une application réelle demandent des cas de test adaptés.
Limites : l’exemple porte sur une fonction ciblée et ne prouve pas la sécurité de l’ensemble d’une application. Dans une mission, les accès, versions et cas vérifiés seraient consignés.