Une correction doit aussi préserver ce qui fonctionne.

Décrire deux parcours

Avant la modification, décrire l’action qui doit être refusée et l’usage qui doit rester possible. Pour chacun, identifier l’acteur, la ressource, son état et la décision attendue. Les contrôles d’autorisation sont à appliquer côté serveur, y compris lorsqu’une interface masque déjà un bouton.

Relire l’état obtenu

Après correction, rejouer les deux parcours et relire le résultat enregistré. Une réponse HTTP favorable ou un écran de succès n’est pas, à lui seul, la preuve que la règle métier a été respectée. Lorsqu’une donnée déterminante change, la validité d’une approbation antérieure doit être réexaminée.

Conserver un compte rendu utile

Le compte rendu conserve le périmètre, les étapes, l’attendu, l’observé, la version testée et les limites. Un scénario réussi ne démontre pas l’absence de toutes les failles. Notre cas de laboratoire illustre cette distinction dans un modèle fermé.

Sources et approfondissements

• OWASP — Authorization Cheat Sheet ↗
• OWASP — Transaction Authorization ↗

Ces références éclairent la démarche. Elles ne désignent ni une certification ni un partenariat HAIDRA.DEV.