Tous les guides
Sévérité MoyenneProtocole HTTP et requêtes côté serveur

Méthodes HTTP dangereuses : comment TRACE, PUT et DELETE sont annoncées

Les serveurs HTTP peuvent annoncer les méthodes qu'ils acceptent en répondant à une requête OPTIONS. Quand cette liste inclut des méthodes dangereuses — TRACE, PUT, DELETE, PATCH ou CONNECT — inutiles en production, vous donnez aux attaquants une carte des points d'entrée potentiels. AppSafe envoie une requête OPTIONS à l'URL racine de votre site et signale toute méthode dangereuse trouvée dans les en-têtes Allow ou Access-Control-Allow-Methods.

Ce que c’est

Tout serveur HTTP peut répondre à une requête OPTIONS avec un en-tête Allow listant les méthodes acceptées : GET, POST, HEAD, OPTIONS, et tout ce qu'il supporte d'autre. Certains frameworks et proxys inverses ajoutent Access-Control-Allow-Methods à la même réponse. Aucun en-tête n'est obligatoire, mais quand ils sont présents, ils indiquent à tout appelant exactement quels verbes tenter.

AppSafe envoie une requête OPTIONS à votre origine et vérifie les deux en-têtes pour des méthodes dans une courte liste de danger : TRACE, PUT, PATCH, DELETE et CONNECT. TRACE obtient son propre résultat de haute sévérité ; les autres sont regroupés à sévérité moyenne. La vérification porte uniquement sur l'annonce — une méthode listée dans Allow peut ou ne peut pas faire quelque chose sur votre serveur, mais l'annoncer encourage l'exploration.

Pourquoi ça compte

TRACE est le plus grave. Il renvoie la requête complète — y compris tous les en-têtes — à l'appelant. Dans les environnements où des identifiants ou des cookies de session sont transmis comme en-têtes de requête, cet écho pourrait exposer ces valeurs à un script de la page via le cross-site tracing (XST). Les navigateurs modernes bloquent TRACE via XHR/fetch, mais les proxys et équilibreurs de charge peuvent ne pas le faire. TRACE n'a aucune utilisation légitime en production : désactivez-le complètement.

PUT, DELETE, PATCH et CONNECT importent car les annoncer invite à des tests. Un PUT sur un chemin accessible en écriture peut déposer des fichiers arbitraires sur le serveur — les serveurs WebDAV en sont l'exemple classique. Un DELETE sans authentification peut permettre à un appelant de supprimer des ressources. Même quand ces méthodes passent par la logique d'autorisation de votre application, les avoir dans l'en-tête Allow concentre la liste de sondage de l'attaquant.

Comment corriger

Désactiver TRACE et restreindre les méthodes dans nginx

Bloquez TRACE au niveau du bloc server et renvoyez 405 pour toute méthode hors de la courte liste que votre app utilise réellement.

server {
  # Reject TRACE completely
  if ($request_method = TRACE) {
    return 405;
  }

  location / {
    limit_except GET HEAD POST OPTIONS {
      deny all;
    }
    # ... your proxy_pass or root ...
  }
}
Restreindre les méthodes dans Express / Next.js

Dans Express, ajoutez un middleware qui rejette toute méthode hors de la liste d'autorisation. Dans les Route Handlers de Next.js, exportez uniquement les fonctions pour les méthodes que vous gérez — le framework renvoie automatiquement 405 pour tout le reste.

// Express: block anything outside the allowlist early
import express from "express";
const app = express();

app.use((req, res, next) => {
  const allowed = new Set(["GET", "HEAD", "POST", "OPTIONS"]);
  if (!allowed.has(req.method)) {
    res.set("Allow", [...allowed].join(", "));
    return res.status(405).json({ error: "Method Not Allowed" });
  }
  next();
});

// Next.js Route Handler — only exported functions are reachable
// (no DELETE export → Next.js returns 405 automatically)
export async function GET(request: Request) {
  return Response.json({ ok: true });
}
// export async function DELETE(...) — don't export this unless you need it
Vérifier avec une requête OPTIONS après le changement

Une fois le serveur mis à jour, confirmez que l'en-tête Allow ne liste plus les méthodes dangereuses.

curl -sI -X OPTIONS https://example.com/ | grep -i allow
# Expected: Allow: GET, HEAD, POST, OPTIONS
# If TRACE, PUT, DELETE, PATCH, or CONNECT appear, the restriction didn't land.

FAQ

Si TRACE est bloqué, pourquoi AppSafe le signale-t-il encore ?

AppSafe lit l'en-tête Allow d'une réponse OPTIONS — il signale ce que le serveur annonce, pas ce qu'il exécute réellement. Un serveur peut revendiquer le support de TRACE dans son en-tête Allow tout en bloquant la méthode derrière une règle de pare-feu. Supprimer TRACE de l'en-tête Allow est la bonne correction car l'en-tête lui-même est le signal que lisent les attaquants.

Annoncer PUT dans l'en-tête Allow signifie-t-il que mon serveur est vulnérable aux téléversements de fichiers ?

Pas nécessairement — PUT peut nécessiter une authentification, être routé vers un handler qui le rejette, ou ne rien faire du tout. Le risque est que cela invite à des tests. Si votre app n'a jamais besoin de PUT pour les appelants non authentifiés, supprimez-le de la réponse Allow.

Comment AppSafe détecte-t-il cela ?

AppSafe envoie une requête HTTP OPTIONS à l'URL racine de votre site et lit les en-têtes Allow et Access-Control-Allow-Methods. Si TRACE, PUT, PATCH, DELETE ou CONNECT apparaissent, le résultat est signalé. TRACE est marqué à haute sévérité ; les autres à sévérité moyenne.

Votre app est-elle concernée ?

AppSafe détecte ce problème et des dizaines d’autres en un seul scan gratuit.

Scanner mon app gratuitement

Guides liés

CORS mal configuré : les pièges du joker et du reflet

Autorisez toutes les origines et n’importe quel site peut lire votre API.

Pages d'erreur verbeuses et stack traces en production

Une stack trace indique aux attaquants exactement où viser.

Introspection GraphQL publique : pourquoi c'est un problème et comment la désactiver

Une seule requête renvoie tout votre schéma. Désactivez-la en production.

Index de répertoires ouverts : quand votre serveur de fichiers liste tout

Un serveur de fichiers qui liste son contenu offre aux attaquants un inventaire gratuit.