Le compte de test pour le scan actif
1 min de lecture
Pourquoi un compte de test ?
Certaines failles n'existent que du point de vue d'un utilisateur connecté, typiquement le cas BOLA/IDOR : un endpoint qui vérifie qu'une session existe, mais jamais que cette session est bien propriétaire de la ressource demandée (par exemple `GET /api/invoices/1234` accessible à n'importe quel utilisateur connecté, pas seulement au propriétaire de la facture 1234). Sans compte de test, ces failles sont invisibles au scan.
Utilisez un compte dédié, jamais un vrai compte, avec des données bidon. Le scan actif fait de vraies actions en son nom (soumission de formulaires, appels RPC) : un compte réel exposerait de vraies données dans les résultats.
Ce que le formulaire demande
Dans le panneau "Scan actif", en mode connexion (l'option par défaut, pas un compte non-authentifié qu'il faudrait décocher) : URL de connexion (optionnelle), email/identifiant, mot de passe. Lancer un scan sans compte de test reste possible, mais c'est un choix explicite : la case correspondante n'est jamais pré-cochée pour vous.
"Enregistrer" est séparé de "Lancer le scan"
Le formulaire de credentials sert au scan que vous êtes en train de lancer, que vous enregistriez ou non. Un bouton distinct, "Enregistrer pour le rescan auto", stocke ces identifiants côté serveur : c'est uniquement ce que le rescan hebdomadaire automatique (planificateur) utilisera la semaine suivante, indépendamment de ce que vous tapez dans le formulaire ensuite.
Pas de formulaire de login classique ?
Si votre app n'a pas de formulaire email/mot de passe standard (OAuth uniquement, SSO...), utilisez plutôt un cookie de session ou un token. Voir l'article dédié, une option "avancée" accessible depuis ce même panneau.