Exploitation active : ce que Vetora prouve une fois ton domaine vérifié

Les quatre vérifications

• Méthode TRACE réellement acceptée — une vraie requête TRACE est envoyée. Si le serveur répond en renvoyant la requête elle-même (comportement conforme à TRACE mais dangereux s'il est activé), c'est confirmé — pas déduit d'un header Allow qui pourrait mentir sur ce qui est réellement implémenté.
• CORS credentialed avec origine reflétée — une origine inventée (jamais autorisée nulle part) est envoyée dans le header Origin. Si le serveur la reflète telle quelle dans Access-Control-Allow-Origin avec Access-Control-Allow-Credentials: true, n'importe quel site peut faire une requête authentifiée (cookies inclus) vers le tien et lire la réponse — bien plus grave qu'un simple Access-Control-Allow-Origin: *, que le check passif détecte déjà mais que les navigateurs refusent par construction d'utiliser avec des identifiants.
• Clé Stripe confirmée active — une clé sk_live_ ou sk_test_ trouvée dans le JavaScript client est utilisée pour un appel GET /v1/balance — l'endpoint que Stripe documente lui-même comme lecture seule, sans effet de bord. Une réponse réussie prouve que la clé authentifie vraiment contre ton compte, pas seulement qu'elle ressemble au bon format. Le solde du compte n'apparaît jamais dans le rapport, seule la clé masquée y figure. Prouver que tu contrôles le domaine ne prouve pas en soi que tu es autorisé à utiliser un identifiant qu'un script présent sur ce domaine expose — un script CDN tiers ou un widget embarqué peut porter la clé Stripe d'une toute autre société — donc ce check aussi ne tourne qu'avec une case à cocher dédiée et explicite, décochée par défaut.
• Écriture Supabase sans authentification — une ligne de test (corps vide, aucune colonne devinée) est insérée dans chaque table Supabase découverte dans le code client, en utilisant uniquement la clé anon publique, puis supprimée immédiatement avec l'id que l'insertion elle-même a renvoyé. Un succès prouve qu'un attaquant peut écrire des données arbitraires, pas seulement les lire. Contrairement aux trois autres, celle-ci écrit dans la base d'un tiers — son nettoyage n'est pas garanti comme l'est un check passif (l'interface REST de PostgREST n'offre aucune transaction inter-requêtes vers laquelle revenir si la suppression échoue après une insertion réussie), donc elle ne tourne qu'avec une case à cocher dédiée et explicite, décochée par défaut.

Non-destructif, par construction

Chacun de ces quatre checks est conçu pour ne jamais pouvoir endommager le site scanné, pas seulement pour essayer d'être prudent :

• TRACE est sans danger par définition (RFC 7231) — un serveur conforme se contente de renvoyer la requête, il n'existe aucun chemin de mutation via cette méthode.
• Le test CORS est une simple requête GET avec un header Origin différent — aucune donnée n'est modifiée.
• La vérification Stripe appelle l'endpoint que Stripe documente explicitement comme lecture seule — sans danger quelle que soit la société à qui la clé appartient réellement, même si elle ne tourne qu'avec son propre consentement puisque posséder le domaine ne prouve pas qu'on est autorisé à utiliser la clé (voir plus haut).
• La ligne insérée dans Supabase est supprimée immédiatement (avec une nouvelle tentative si la première échoue), avec l'id que l'insertion elle-même a renvoyé — jamais un filtre de suppression deviné. Si aucun id ne revient dans la réponse, la suppression est simplement annulée plutôt que risquer de toucher la mauvaise ligne : un unique enregistrement de test orphelin est un risque bien plus faible qu'une suppression mal ciblée. Si le nettoyage échoue quand même après la seconde tentative, le rapport le dit explicitement plutôt que d'affirmer un succès qui n'a pas eu lieu — et ce check précis ne tourne qu'avec un consentement séparé, puisque c'est le seul des quatre qui écrit dans la base d'un tiers.

Volontairement exclu de ce lot pour la même raison inverse : une vraie requête PUT/DELETE contre un chemin arbitraire (prouver qu'on possède un domaine ne prouve pas que chaque endpoint est sûr à modifier), et la vérification de clés AWS (SigV4 exige la paire ID + secret ; le secret associé n'a aucun format détectable par un scanner passif).

Comment ça se déclenche

Une fois ton domaine vérifié, un bouton dédié apparaît sur la page de résultat du scan. Chaque scan ne peut lancer ces checks qu'une seule fois, et la route est limitée à un petit nombre de tentatives par IP — ce sont de vraies requêtes sortantes vers un tiers, pas une relecture de données déjà collectées.

# Deux méthodes possibles pour prouver la propriété du domaine
# (une seule des deux suffit) :

# Option 1 — DNS TXT
_vetora-challenge.exemple.com  TXT  "vetora-verify=<token>"

# Option 2 — fichier well-known
https://exemple.com/.well-known/vetora-verification.txt