Désactiver les méthodes HTTP dangereuses (TRACE, PUT, DELETE)
Le protocole HTTP définit une dizaine de « méthodes » (ou verbes) qui décrivent l'action demandée à un serveur : GET pour lire une page, POST pour envoyer un formulaire, mais aussi PUT, DELETE, TRACE, TRACK, OPTIONS, CONNECT… Par défaut, beaucoup de serveurs acceptent plus de méthodes qu'un site n'en a réellement besoin.
Or chaque méthode active est une porte ouverte de plus. Certaines, comme TRACE ou TRACK, ont servi par le passé à des attaques de vol de session ; d'autres, comme PUT et DELETE, permettraient — en cas de mauvaise configuration — de déposer ou de supprimer des fichiers sur votre serveur. Le principe de moindre privilège est limpide : n'autorisez que ce dont vous vous servez, c'est-à-dire, pour l'immense majorité des sites, GET, POST et HEAD.
Quelles méthodes posent problème
TRACE et TRACK renvoient en écho la requête reçue. Combinées à une autre faille, elles ont historiquement permis le Cross-Site Tracing (XST), une technique de vol d'informations d'authentification normalement inaccessibles au JavaScript. Elles n'ont aucune utilité légitime sur un site de production.
PUT et DELETE servent à créer ou supprimer des ressources. Sur un site vitrine ou un blog, elles ne devraient jamais être exposées : si une mauvaise configuration ou un module les active sans contrôle d'accès, un attaquant pourrait téléverser un fichier malveillant (webshell) ou effacer du contenu. OPTIONS, enfin, n'est pas dangereuse en soi mais révèle la liste des méthodes acceptées — c'est d'ailleurs ce que CheckCyber utilise pour auditer votre serveur.
Comment CheckCyber le détecte
L'audit envoie une requête OPTIONS standard à votre site, parfaitement non-intrusive, et lit l'en-tête Allow renvoyé par le serveur. Cet en-tête énumère les méthodes acceptées. Si TRACE, PUT, DELETE ou TRACK y figurent, le contrôle est signalé afin que vous puissiez restreindre la configuration.
Restreindre les méthodes
L'objectif est de n'autoriser que GET, POST et HEAD, et de désactiver explicitement TRACE. Voici comment procéder sur les deux serveurs les plus répandus.
# N’autorise que GET, POST, HEAD
<LimitExcept GET POST HEAD>
Require all denied
</LimitExcept>
# Désactive TRACE (à placer dans la config principale si possible)
TraceEnable off# Renvoie 405 pour toute méthode non autorisée
if ($request_method !~ ^(GET|POST|HEAD)$) {
return 405;
}Vérifier le résultat
Le plus simple est de relancer un audit CheckCyber : l'en-tête Allow ne doit plus contenir que GET, POST, HEAD (et éventuellement OPTIONS). En ligne de commande, vous pouvez aussi tester directement, par exemple avec curl -X DELETE -i https://votresite.fr : le serveur doit répondre 405 Method Not Allowed (ou 403). Une réponse 200 ou 204 indiquerait que la méthode est toujours active.
Pensez à tester depuis l'extérieur et en production, car un module de cache ou un pare-feu applicatif (WAF) peut modifier le comportement entre votre poste et le serveur réel.
[ FAQ // QUESTIONS FRÉQUENTES ]
▸Mon API REST a besoin de PUT et DELETE, que faire ?
Autorisez ces méthodes uniquement sur les chemins de l'API qui en ont besoin (par exemple /api/), et protégez-les systématiquement par authentification et contrôle d'accès. Désactivez-les partout ailleurs, notamment sur les pages publiques et les répertoires de fichiers.
▸Désactiver TRACE peut-il casser mon site ?
Non. Aucun navigateur ni aucun usage normal d'un site web n'emploie TRACE. La désactiver n'a aucun effet visible pour vos visiteurs et ferme un vecteur d'attaque connu.
▸Le code 405 est-il un problème pour le référencement ?
Non. Le 405 ne concerne que les méthodes interdites ; Google explore votre site avec GET et HEAD, qui restent autorisées. Vos pages continuent d'être lues et indexées normalement.
[ PASSEZ À L’ACTION ]
Votre site est-il concerné ?
Lancez un audit de surface gratuit et obtenez en quelques secondes la liste exacte de vos failles, avec le correctif pour chacune. Anonyme, sans inscription.
▶ Auditer mon site[ À LIRE AUSSI ]
[ CheckCyber // MIS À JOUR LE 2026-06-29 ]