Du constat technique à la décision.

Un salarié accède aux salaires de ses collègues.

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.

La requête révèle le défaut.

1. 01Se connecter avec le compte de démonstration d’un salarié du service commercial.
2. 02Remplacer le numéro d’un document commercial autorisé par celui du fichier de paie réservé aux RH.
3. 03Constater que le serveur retourne les salaires alors que ce compte n’a aucun droit RH.

Vérifier le droit sur ce document.

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.

Protéger les RH. Garder leur accès.

• Compte RH habilité200 · autorisé
• Salarié commercial403 · refusé
• Compte sans session401 · refusé

Ces résultats illustrent le re-test attendu. Ils ne correspondent pas à des tests réalisés chez un client.

Un bouton caché ne protège pas un export.

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.

La requête révèle le défaut.

1. 01Se connecter avec un compte disposant uniquement du rôle standard.
2. 02Appeler directement l’endpoint d’export de la console d’administration.
3. 03Constater que masquer le bouton n’empêche pas l’API de retourner les données.

Contrôler la fonction côté serveur.

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.

Réserver l’export au bon rôle.

• Administrateur autorisé200 · autorisé
• Utilisateur standard403 · refusé
• Session absente ou expirée401 · 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.

Le prix du panier ne se décide pas dans le navigateur.

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.

La requête révèle le défaut.

1. 01Ajouter au panier l’article fictif affiché à 120 €.
2. 02Modifier le prix transmis par le navigateur à 1 €, sans changer le produit ni la quantité.
3. 03Observer la commande créée à 1 € : le serveur a utilisé une valeur fournie par le client.

Recalculer depuis le catalogue.

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.

Facturer le montant autorisé.

• Prix navigateur modifié à 1 €120 € · recalculé
• Quantité négative422 · 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.