Audits authentifiés
Créez une session de test réutilisable avec Cookie, Bearer ou en-tête personnalisé, puis vérifiez la couverture protégée en toute sécurité.
Réutiliser une session de test protégée
Une session de test est un identifiant d’authentification nommé, enregistré pour un domaine vérifié. Les audits complets et personnalisés peuvent la réutiliser : vous n’avez donc pas besoin de récupérer ou recoller le secret à chaque exécution. Les audits légers restent toujours publics.
VICE chiffre les secrets enregistrés. Seuls les workers de vérification et d’audit les utilisent. Votre mot de passe n’est jamais nécessaire.
Les sessions enregistrées restent associées au domaine vérifié et peuvent être recherchées, modifiées, renouvelées ou révoquées.
- Créez jusqu’à cinq sessions par domaine vérifié.
- Choisissez une expiration comprise entre une heure et trente jours.
- Les identifiants restent sur le site vérifié ou sur le projet Supabase exact configuré pour sa session.
Choisir la méthode d’authentification
Utilisez la même méthode qu’une requête réussie après connexion. Ouvrez votre application avec un compte de test dédié, puis inspectez une requête protégée dans les outils de développement du navigateur avant de créer la session.
Inspectez une requête de même origine réussie et copiez uniquement la valeur d’authentification attendue par la méthode sélectionnée.
- Authentification Supabase
- Jeton Bearer : la requête contient un en-tête Authorization dont la valeur commence par Bearer.
- En-tête Cookie : le navigateur authentifie la requête avec un ou plusieurs cookies propriétaires.
- En-tête personnalisé : l’application utilise un autre en-tête comme x-api-key ou x-auth-token.
Obtenir un jeton Bearer
Un jeton Bearer est un jeton d’accès secret : tout système qui possède un jeton valide peut le présenter au serveur. Il s’agit souvent d’un JWT, mais tous les jetons Bearer ne sont pas des JWT. Traitez la valeur complète comme un secret équivalent à un mot de passe.
Connectez-vous avec le compte de test dédié, ouvrez Outils de développement > Réseau, rechargez une page protégée, puis sélectionnez une requête de même origine qui ne réussit qu’une fois connecté. Dans En-têtes > En-têtes de requête, recherchez Authorization: Bearer suivi du jeton.
- VICE accepte le jeton utilisateur avec ou sans le préfixe Bearer.
- Si aucun en-tête Authorization n’apparaît, l’application utilise probablement des cookies ou un en-tête personnalisé.
Authentification Supabase
Si votre application utilise la connexion Supabase, choisissez Supabase Auth. Un jeton Bearer seul ne suffit pas toujours à rétablir la session dans le navigateur.
Connectez-vous avec un compte de test. Dans les outils de développement du navigateur, ouvrez Application > Local Storage ou Session Storage. Sous votre site, copiez la valeur JSON de sb-<project-ref>-auth-token dans le champ d’import facultatif de session.
Utilisez une clé publique ou l’ancienne clé anon. Les clés secrètes et service-role sont refusées.
- Le jeton d’accès identifie le compte ; le jeton de renouvellement renouvelle sa session. Copiez les deux depuis la même connexion, jamais seulement les noms des champs.
- VICE remplit les deux jetons et détecte l’URL du projet. Ajoutez la clé publique depuis les paramètres Supabase. Utilisez Saisir les jetons manuellement uniquement si vous ne pouvez pas importer la session.
- Utilisez une page privée de votre site, pas l’API Supabase. Une déconnexion ou une révocation d’accès peut invalider la session avant son expiration dans VICE.
Obtenir un en-tête d’authentification personnalisé
Certaines applications authentifient les requêtes API avec un en-tête propre au produit plutôt qu’avec Authorization ou Cookie. Inspectez une requête protégée réussie dans Réseau > En-têtes > En-têtes de requête, puis identifiez l’en-tête stable qui transporte l’identifiant.
- Saisissez le nom de l’en-tête séparément, par exemple x-api-key ou x-auth-token.
- Collez uniquement la valeur brute de l’en-tête dans le champ secret, sans le nom de l’en-tête ni les deux-points.
- N’utilisez pas d’en-têtes de routage ou de transport comme Host, Origin, Referer, Connection, Content-Length, Transfer-Encoding ou Proxy-Authorization.
Page accessible après connexion
Vous pouvez laisser ce champ vide. VICE recherche automatiquement une page privée en suivant les liens et les redirections de votre site, puis la vérifie avec et sans votre session de test. La page trouvée est mémorisée, mais l’accès est vérifié à nouveau avant chaque audit.
Si VICE ne trouve pas de page permettant de prouver l’accès privé, cliquez sur « Choisir une page manuellement » dans le résultat de la vérification, ou ouvrez « Options avancées » et renseignez « Page accessible après connexion ». Les adresses déjà enregistrées sont conservées ; videz ce champ pour passer à la détection automatique.
Il s’agit d’une page qui existe déjà dans votre application et qui nécessite une connexion, comme l’espace personnel ou le tableau de bord. VICE ouvre cette même page avec et sans votre session de test pour vérifier qu’elle donne réellement accès à l’espace privé.
Connectez-vous à votre application avec le compte de test, ouvrez une page privée accessible à ce compte et copiez son adresse finale dans la barre d’adresse du navigateur. Collez-la dans « Page accessible après connexion ». Par exemple : https://app.example.com/dashboard ou simplement /dashboard. Remplacez cet exemple par l’adresse réelle de votre page, en respectant les majuscules et les minuscules.
Ouvrez la même adresse dans une fenêtre de navigation privée, sans vous connecter. Elle doit demander une connexion ou refuser l’accès à l’espace privé. Si elle affiche le même contenu privé, choisissez une autre page. Gardez votre compte de test connecté dans la fenêtre d’origine : une déconnexion peut invalider la session copiée.
Laissez la page vide pour la détection automatique, ou indiquez une page privée dans « Options avancées ».
- Utilisez exactement le site enregistré comme domaine dans VICE. Pour un environnement de test, utilisez son adresse, pas celle du site en production. Avec Supabase Auth, indiquez une page de votre application, pas le tableau de bord Supabase ni l’URL de son API.
- N’utilisez ni la page de connexion, ni une page d’accueil publique, ni l’adresse de retour de connexion, ni un lien de connexion à usage unique. L’adresse ne doit contenir aucun jeton ni autre secret.
- Choisissez une page dont l’ouverture est sans conséquence : sa consultation ne doit rien créer, supprimer, acheter ou envoyer.
- Vous n’avez pas besoin de créer une page spéciale ni de modifier votre code. Cette page sert à vérifier l’accès et de point de départ pour explorer l’application : ce n’est pas la seule page que l’audit peut examiner.
- Le texte de confirmation dans les paramètres avancés est facultatif. Si nécessaire, indiquez un libellé stable déjà visible uniquement après connexion, comme « Paramètres du compte ». N’ajoutez pas de texte à votre application et n’utilisez ni nom, ni adresse e-mail, ni valeur changeante. Pour retirer un texte de confirmation enregistré, cochez sa case de suppression ; laisser le champ vide le conserve.
- Un jeton Supabase valide ne garantit pas l’accès à votre application : il peut encore manquer un rôle ou l’accès à un espace de travail au compte de test. Un échec de vérification de la page ne signifie donc pas forcément que le jeton a expiré.
Enregistrer et vérifier l’accès
Enregistrer et vérifier l’accès sauvegarde la session, puis compare la page avec et sans celle-ci. Cette vérification gratuite peut attendre un worker disponible. En cas d’échec, votre session reste enregistrée et modifiable.
Un accès vérifié confirme une différence sur cette page, pas une couverture complète de votre application. Le résultat explique l’échec : retour à la connexion, texte de confirmation absent, page publique ou connexion indisponible.
Cette vérification ne consomme aucun crédit d’audit.
Sélectionner la session pour un audit
Depuis la vue d’ensemble du domaine ou la page Audits, choisissez Lancer un audit. Sélectionnez Complet ou Personnalisé, basculez Accès à l’application sur Session de test, puis choisissez une session nommée active dans la liste.
Sélectionnez une session enregistrée uniquement pour une couverture complète ou personnalisée qui nécessite des routes protégées.
- Les audits légers n’utilisent pas de session de test.
- L’audit enregistre la référence de la session sélectionnée au lieu de copier le secret dans l’historique.
- Chaque audit vérifie à nouveau l’accès. Si celui-ci n’est pas vérifié, les contrôles de sécurité s’arrêtent et le quota ou crédit réservé est restitué. Choisissez Surface publique pour auditer sans session.
Renouveler ou révoquer la session
Utilisez l’icône crayon dans Paramètres du domaine > Sessions de test pour renommer la session, ajuster son chemin protégé ou son marqueur, renouveler l’identifiant ou le révoquer.
- Laissez Nouveau secret de session vide pour conserver l’identifiant chiffré et son expiration actuelle.
- Fournissez un nouveau secret pour renouveler l’identifiant et appliquer une nouvelle expiration.
- Supprimer la session ouvre une confirmation et révoque immédiatement la session.
Continuer avec VICE
Consultez le workflow d'audit géré derrière ce guide.