Pour quelle décision ?
Examiner si un signalement peut être reproduit et si le correctif proposé répond au problème. Chaque conclusion garde ses observations avant et après.
Trust Verify · Démonstration sur des cas fictifs
Le correctif bloque-t-il
le défaut signalé ?
Rejouez un accès interdit avant et après correction. Vérifiez aussi qu’un utilisateur autorisé peut toujours utiliser la fonction.
Pour qui ?
Développeurs et responsables techniques qui reçoivent des rapports de vulnérabilités ou doivent examiner une correction.
Cette page exécute uniquement les fonctions fictives embarquées dans votre navigateur. Aucun site n’est scanné et aucun code externe n’est accepté. Les statuts 200, 401 et 403 sont simulés.
Le point à vérifier
Cliquez sur « Rejouer ce cas » pour calculer le résultat et afficher les observations.
| Essai | Règle attendue | Version initiale | Version corrigée |
|---|
Résultats du rejeu dans votre navigateur
Ces résultats décrivent un corpus écrit pour cette expérience. Ils ne mesurent pas la précision sur des rapports réels.
| Cas | Résultat |
|---|
1. Reproduire
Le défaut est reproduit si un accès interdit réussit sur la version initiale. Un usage légitime sert de contrôle.
2. Contrôler le correctif
Les accès interdits doivent être refusés et les usages légitimes doivent continuer à fonctionner. Bloquer tous les utilisateurs ne suffit pas.
3. Garder les limites
Une cible absente donne un résultat indéterminé. Un cas non reproduit ne certifie pas l’absence de faille.
Passer à un cas réel
La réception de projets et l’exécution de démonstrations tierces demandent un environnement isolé et un périmètre de test convenu. Cette fonctionnalité n’est pas encore ouverte.