Pourquoi tester à nouveau si vos systèmes n’ont pas changé ?

Un portail de recrutement peut fonctionner normalement tout en laissant un candidat lire les CV d’autres personnes. Une boutique photo peut traiter correctement les paiements tout en envoyant l’original au navigateur avant l’achat. Le défaut porte sur ce que le système autorise, pas nécessairement sur l’apparence de ses pages publiques.

La question utile est : que peut faire une personne alors qu’elle ne devrait pas en avoir le droit ?

Deux raisons différentes de tester à nouveau

Une modification logicielle ou d’infrastructure peut ouvrir un nouveau chemin. Un contrôle des droits disparaît lors du remplacement d’une route API, ou un réglage de stockage rend des fichiers privés accessibles. Comparer les deux versions avec les mêmes comptes de test aide à établir ce qui a changé.

Un nouveau modèle d’IA constitue un autre déclencheur. Le système peut rester identique, mais un test relie désormais des indices qu’un essai précédent avait manqués. La faille n’est pas nouvelle pour autant. Un seul succès ne prouve pas non plus que le modèle explique à lui seul la découverte : accès, outils, instructions, budget et variations entre essais comptent aussi.

L’AI Security Institute britannique a comparé des modèles sortis sur dix-huit mois dans une attaque simulée. La progression moyenne est passée de 1,7 à 9,8 étapes avec le même budget de traitement par l’IA, sans défenseur actif. Cela montre un progrès sur une tâche contrôlée, pas un taux d’intrusion dans de vraies organisations. Lire l’évaluation.

Suivre le parcours sans exagérer le résultat

Dans un test applicatif, un compte ordinaire est souvent un point de départ plus utile qu’une liste d’en-têtes manquants. Peut-il consulter un autre dossier ? La réponse révèle-t-elle un lien vers un document ? La route de téléchargement vérifie-t-elle les mêmes droits ?

Deux dossiers de test peuvent démontrer cette chaîne. « Un second dossier de test était accessible » ne doit pas devenir « toute la base a été volée ». Le rapport doit distinguer accès démontré, exposition plus large possible et abus réel.

Il en va de même pour les paiements. Masquer un bouton ne protège pas un fichier si le serveur a déjà fourni un lien utilisable. Le droit lié à l’achat doit être vérifié là où l’accès est accordé, y compris dans le stockage et le CDN.

Ce que le rapport doit conserver

• La version testée, le niveau d’accès, les requêtes et les réponses pertinentes.
• Ce qu’un attaquant pourrait faire et où la démonstration s’est arrêtée.
• Le défaut de droits ou de processus à l’origine du problème.
• Le déclencheur du test et les preuves qui expliquent son succès.
• La correction et les tests des accès interdits comme des usages légitimes.

Ces questions concernent les applications, API et infrastructures connectées, avec une équipe de sécurité interne ou un prestataire.

EverBreach développe des simulations d’attaques par IA selon cette approche. Le scanner externe actuel reste plus limité. Le rapport exemple illustre la profondeur visée avec des scénarios applicatifs clairement fictifs. Discutons d’une analyse pour convenir des disponibilités et du périmètre adapté.