Audit ciblé · Site réel · 7 novembre 2026
Un formulaire local pouvait placer son contenu dans l’URL.
Défaut reproduit sur le code d’INOBIC, corrigé puis vérifié : empêcher qu’un échec JavaScript transforme une préparation d’email en requête HTTP.
Revue interne avec des données de test fictives. Les résultats décrivent un défaut reproduit, sans établir l’existence d’un incident passé ni constituer un audit indépendant.
Périmètre réel de la revue
Code HTML et JavaScript de la vitrine, configuration de l’hébergement Azure, domaines, environnements, noms des paramètres applicatifs et attributions de rôles visibles à la session. La lecture Azure est limitée à la ressource du site et aux droits qui lui sont applicables. Les valeurs de secrets n’ont pas été utilisées pour l’audit.
Le formulaire existe sur la page contact et sur la page de demande d’audit. Il doit seulement préparer un email dans la messagerie du visiteur. Aucun endpoint de collecte n’est prévu.
Les tests d’échec ont été effectués sur une copie locale, avec un texte synthétique. Les contrôles publics sont limités à des lectures HTTP non destructives. Aucun système tiers, base client ou test de charge n’entre dans ce périmètre.
Constat confirmé : le comportement par défaut du navigateur
Le formulaire initial ne précisait ni méthode ni action. Le code JavaScript interceptait normalement la soumission pour ouvrir une URL mailto. Si ce script était bloqué ou indisponible, le navigateur pouvait effectuer une requête GET vers la page courante, avec les valeurs des champs dans la query string.
/before.html?need=application&message=AUDIT-SYNTHETIQUE-AUCUNE-DONNEE-REELLE&timing=&budget=Cette URL a été observée dans le navigateur local après avoir rempli et soumis le formulaire issu du code réel, avec ses scripts retirés pour simuler leur indisponibilité.
Impact et conditions
Risque de confidentialité conditionnel, priorité de correction modérée. Le texte saisi peut entrer dans l’historique du navigateur et dans les journaux de requêtes des couches qui traitent l’URL. Un lien copié pourrait aussi transporter ce texte. La destination reste le site INOBIC ; aucune exfiltration vers un tiers n’a été démontrée.
La condition nécessaire est l’échec du gestionnaire JavaScript, suivi d’une soumission contenant des données. Aucune preuve de fuite passée ou de consultation effective de journaux n’a été recueillie. Aucun score CVSS chiffré n’est attribué sans analyse plus complète du contexte.
Correctif en trois couches
- Initialisation fermée : le formulaire est masqué dans le HTML et n’est révélé qu’après installation des gestionnaires. Le masquage ne dépend pas uniquement d’une feuille CSS potentiellement en cache.
- Comportement HTML explicite : la méthode POST remplace le GET implicite. Le gestionnaire normal continue de prévenir la soumission native et de préparer l’email.
- Protection côté réponse HTTP : la directive CSP form-action none bloque les soumissions HTML, même si le formulaire devenait visible sans son gestionnaire.
Un lien email direct reste visible sans JavaScript. La version du script est ajoutée à son URL pour éviter de réutiliser une copie obsolète. Les retours à la ligne du brouillon, auparavant littéraux, ont aussi été corrigés.
Tests des correctifs
- Avant : le marqueur fictif apparaît dans l’URL après soumission sans script.
- Après, sans script : le formulaire reste invisible ; le contact email direct reste disponible.
- Après, fonctionnement normal : formulaire visible, choix de besoin conservé, résumé copiable, vrais retours à la ligne et absence du texte dans l’URL HTTP.
- Défense en profondeur : une fixture locale expose volontairement le formulaire sans gestionnaire ; la CSP empêche sa navigation native.
- Tests automatisés : encodage, annulation de la soumission native, ordre d’initialisation, succès du presse-papiers et repli manuel en cas de refus.
Ces tests ne couvrent pas tous les navigateurs ni la livraison d’un email. Aucun message n’a été envoyé pendant la validation.
Autres contrôles et limites
L’inventaire du site ne comporte que deux scripts JavaScript applicatifs et aucune dépendance JavaScript tierce. Aucun sink HTML dynamique ou appel eval n’a été trouvé dans ces scripts. La recherche ciblée de secrets n’a pas remonté de résultat ; elle ne remplace pas une analyse exhaustive de tout l’historique.
Les réponses à cinq chemins ciblés de fichiers de configuration, de dépôt et d’API ont retourné 404. Les domaines Azure du site sont valides ; aucun paramètre applicatif n’est configuré sur cette ressource. Ces observations ne démontrent pas l’absence de tout fichier exposé.
La CSP est complétée par des restrictions de scripts, de connexions et de frames. Les styles inline restent autorisés pour préserver les pages existantes : c’est une limite explicitement conservée. Les permissions de fonctionnalités navigateur inutilisées sont désactivées.
Les droits hérités utilisés pour administrer Azure demandent une revue du moindre privilège. Leur détail reste dans le rapport privé ; aucune permission de l’abonnement n’a été modifiée lors de cette intervention. La revue ne couvre pas tout le tenant Entra ID.
Pièces expurgées et reproduction
Les pièces publiées ne contiennent que le code du site public, des données fictives, les différences de configuration et les résultats des tests. Les identifiants d’abonnement, utilisateurs, accès et informations de session sont exclus.
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 →