Scanner de méthodes HTTP dangereuses

Comment fonctionne cette vérification

Scanaris envoie une requête OPTIONS à l'URL analysée, sans suivre les redirections, et lit deux en-têtes de la réponse : Allow, par lequel un serveur déclare les méthodes qu'il accepte sur cette route, et Access-Control-Allow-Methods, celui de CORS. Si l'un des deux liste TRACE, TRACK, PUT, DELETE ou CONNECT, il ouvre un constat de sévérité faible avec la liste. C'est une vérification prudente : elle ne signale que ce que le serveur annonce explicitement. Elle n'envoie aucun PUT ni DELETE de test, et si le serveur ne répond pas à l'OPTIONS ou ne renvoie pas ces en-têtes, il n'y a pas de constat.

Pourquoi c'est important

Un site normal a besoin de GET, HEAD, POST et, pour CORS, OPTIONS. Le reste, ce sont des méthodes avec une histoire. TRACE renvoie la requête telle qu'elle a été reçue, en-têtes compris ; combiné à une autre faille, il permet de lire des cookies marqués HttpOnly (l'attaque s'appelle Cross-Site Tracing). PUT et DELETE créent, remplacent ou suppriment des ressources : sur un serveur de fichiers mal configuré, un PUT dépose un fichier dans le répertoire public. CONNECT transforme le serveur en proxy. Qu'ils soient activés ne signifie pas qu'ils fonctionnent sans authentification, d'où la sévérité faible ; mais les annoncer sans les utiliser, c'est de la surface d'attaque gratuite.

Comment corriger

• Apache : TraceEnable Off dans la configuration principale (TRACE est activé par défaut sur les anciennes versions). Pour le reste, dans le Directory ou Location de ton site : <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx : n'implémente pas TRACE. Pour limiter le reste dans un bloc location : limit_except GET POST HEAD OPTIONS { deny all; }. Si tu utilises if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, place-le au niveau server.
• IIS : le module WebDAV est la cause habituelle des PUT et DELETE annoncés. Désinstalle-le si tu ne l'utilises pas, et dans web.config limite les verbes avec requestFiltering/verbs.
• Express et API : si ton API utilise PUT ou DELETE avec authentification, il est légitime que Access-Control-Allow-Methods les liste ; ce qu'elle ne doit pas faire, c'est les lister sur tout le site ou utiliser *. Dans le middleware CORS, mets methods: ['GET', 'POST'] sur les routes publiques et élargis seulement là où c'est nécessaire.
• Vercel, Netlify, Cloudflare Pages : n'annoncent pas ces méthodes par défaut. Si le constat apparaît, il vient généralement d'un en-tête CORS que tu as configuré toi-même avec la liste complète.

Vérifie que c'est corrigé

curl -si -X OPTIONS https://tondomaine.com | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://tondomaine.com | head -1

Dans la première, ni Allow ni Access-Control-Allow-Methods ne devraient inclure TRACE, TRACK, PUT, DELETE ou CONNECT sur les routes publiques. La seconde doit renvoyer 405 ou 403, jamais 200 avec ta requête reflétée dans le corps.

Questions fréquentes

Mon API REST utilise PUT et DELETE. Dois-je les retirer ?

Non. Ce qui compte, c'est que ces routes exigent une authentification et que l'en-tête CORS ne les annonce pas pour tout le domaine ni pour n'importe quelle origine. Si l'analyse vise la racine de ton API, tu peux marquer le constat de sévérité faible comme accepté une fois cela vérifié. La configuration des origines est examinée par CORS permissif.

Access-Control-Allow-Methods liste des méthodes, mais sans Allow. Est-ce pareil ?

Pas tout à fait. Allow décrit ce que le serveur accepte ; l'en-tête CORS décrit ce qu'il autorise aux pages d'autres origines. Les deux sont lus parce que les deux sont de l'information que tu donnes. Ce que signifie chaque partie d'une réponse CORS est expliqué dans CORS mal configuré.

Pourquoi OPTIONS n'est-il pas considéré comme dangereux ?

Parce que c'est la méthode avec laquelle le navigateur interroge CORS avant certaines requêtes. Le bloquer casse les appels entre domaines. Il est inoffensif et nécessaire.