01 · Constater
Un état initial identifié
Défaut observé dans le navigateur à partir du code du site. Conditions de reproduction et impact explicités.
Dossier technique · Code, configuration et vérification
Une correction doit pouvoir se vérifier.
Partir d’un état observable. Expliquer le changement. Fournir les éléments qui permettent de le contrôler.
Cas interne réalisé sur inobic.fr · 7 novembre 2026 · Sources et résultats disponibles
Audit interne : un défaut réel du formulaire corrigé
HTML / JavaScript · Azure
Quand le JavaScript échoue, où part le message ?
La revue du code d’INOBIC a révélé qu’une soumission sans JavaScript pouvait placer le texte du formulaire dans l’URL. Le défaut a été reproduit localement, corrigé puis retesté avec des données fictives. Le dossier expose les conditions du risque, les protections ajoutées et les pièces vérifiables.
Revue interne du site INOBIC. Sources et résultats des tests disponibles dans ce dossier. Ce cas porte sur une revue ciblée du code, de la configuration Azure et du parcours de contact. Il n’est pas présenté comme une mission client ou un pentest.
Lire les constats, décisions et limites →Les éléments qui rendent le travail contrôlable
02 · Corriger
Un changement lisible
Correctif JavaScript, repli sans script et blocage des soumissions HTML par CSP. Diff du code disponible.
03 · Vérifier
Des résultats consultables
Tests avant/après, absence de JavaScript, copie et repli manuel. Reproduction locale sans données réelles.
Pièces techniques
Complément pédagogique : contrôle d’accès .NET
Un exemple isolé illustre la correction d’un contrôle d’accès par organisation et propriétaire. Les mêmes dix tests sont exécutés avant et après correction. Il complète le cas interne ; il ne démontre pas une expérience de mission .NET ou Azure chez un client.
Consulter le laboratoire et ses résultats
Démonstration en console avec des identités simulées et des données fictives, sans serveur ni base de données réelle.
Rapport du laboratoire · Sources C# · Résultats et empreintes
Pour votre projet : partir de votre code et de vos risques
Le cadrage détermine les composants à examiner, les accès nécessaires, les méthodes autorisées et les livrables attendus. Une mission sur votre application doit produire des constats liés à votre contexte et des corrections vérifiables par votre équipe.
Définir un périmètre d’auditLes documents présentés sont auto-produits. Aucun audit indépendant, référence client ou agrément n’est revendiqué.
Des bonnes pratiques reliées à des preuves
Autorisation écrite, contrôles adaptés au risque, preuves minimisées et contre-vérification des corrections. Notre méthode précise aussi les contrôles non réalisés et les risques restant ouverts.
Découvrir la méthode et les checklists d’audit →