Autoriser uniquement les méthodes HTTP valides : bloquer les requêtes indésirables avec Nginx 405/444 [ r1 ]

Autoriser uniquement les méthodes HTTP valides : couper les requêtes indésirables avec Nginx 405/444

En surveillant les logs d’une application web en production, on peut parfois rencontrer des situations inattendues.

\n
• Je pensais n’utiliser que GET / POST / PUT / DELETE
\n
• Mais un log révèle une méthode inconnue
\n

Par exemple, on peut voir PROPFIND (une méthode WebDAV) dans les logs. L’application va probablement répondre « méthode non prise en charge », mais la vraie question est la suivante.

Faut-il vraiment que l’application traite ces requêtes parasites\u202f?\nLa réponse habituelle est « non ». Il est donc propre de laisser Nginx filtrer les méthodes non autorisées dès le premier point d’entrée.

Pourquoi bloquer dès Nginx\u202f?

On peut aussi bloquer au niveau de l’application, mais dès que la requête atteint l’application, des coûts sont déjà engagés.

\n
• Entrée WSGI/ASGI
\n
• Middleware, journalisation, authentification partielle
\n
• Logs d’application encombrés, rendant les vrais problèmes difficiles à repérer
\n
• En cas de forte charge, l’accumulation de trafic inutile
\n

En revanche, bloquer avec Nginx\u202f:

\n
• Arrêt immédiat au plus haut niveau → coût minimal
\n
• Logs d’application propres → facilité de maintenance
\n
• Surface d’attaque réduite → élimination des méthodes inutiles
\n

En une phrase\u202f:

\n

L’application construit le produit, Nginx joue le rôle de gardien.

\n

Les méthodes étranges dans les logs sont rarement du trafic normal

PROPFIND est un exemple typique.

\n
• Scan de base pour vérifier si WebDAV est activé
\n
• Si PUT/MKCOL est ouvert par erreur, l’attaquant tente de passer à l’étape suivante
\n
• User‑Agent vide ou requêtes HTTP/1.0 simplifiées sont fréquentes
\n

Le point clé est simple.

Si notre service n’utilise pas cette méthode, il est très peu probable que la requête soit légitime.\nIl n’est donc pas nécessaire d’envoyer la requête à l’application pour y répondre poliment.

Stratégie simple\u202f: opérer avec une liste blanche

Le principe est « ouvrir uniquement ce qui est nécessaire, fermer le reste ».

\n
• Pages web/statics\u202f: généralement GET et HEAD suffisent
\n
• API\u202f: autoriser POST/PUT/PATCH/DELETE uniquement sur les endpoints requis
\n

Toutes les autres méthodes (ex. PROPFIND, MKCOL, LOCK, etc.) sont bloquées si elles ne sont pas utilisées.

405 vs 444\u202f: quelle réponse choisir\u202f?

Il existe deux approches principales pour bloquer.

1) 405 Method Not Allowed

\n
• Standard et compréhensible
\n
• Informe clairement le client légitime qu’une méthode est interdite
\n

2) 444 (Nginx\xa0: fermeture de la connexion sans réponse)

\n
• Ferme la connexion sans message
\n
• Donne moins d’indications aux scanners/robots
\n
• Calme et propre du point de vue de la gestion (« on ne laisse pas de trace »)
\n

En pratique, on combine les deux\u202f:

\n
• Méthodes sans valeur pour le web public\u202f: 444
\n
• Clients légitimes susceptibles de faire une erreur\u202f: 405
\n

Exemple de configuration Nginx\u202f: deux modèles pour « autoriser uniquement les méthodes »

Les exemples ci‑dessous sont prêts à copier‑coller.

Modèle A\u202f: GET/HEAD par défaut, API avec méthodes supplémentaires

server {\n    # ... listen/server_name etc ...\n\n    # 1) Par défaut : web/statics ne permettent que GET/HEAD\n    location / {\n        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # ou 405\n        proxy_pass http://app;\n    }\n\n    # 2) API : autoriser uniquement les méthodes nécessaires\n    location /api/ {\n        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }\n        proxy_pass http://app;\n    }\n}\n

\n
• / est souvent limité à GET/HEAD car il s’agit de pages de consultation.
\n
• /api/ peut nécessiter OPTIONS pour le CORS.
\n

Modèle B\u202f: bloquer explicitement les méthodes « étranges » (début léger)

location / {\n    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }\n    proxy_pass http://app;\n}\n

\n
• Couper immédiatement les requêtes parasites observées en production
\n
• À long terme, le modèle A (liste blanche) est plus sûr et plus facile à gérer.
\n

\n

Note\u202f: bien que l’usage de if soit parfois déconseillé dans Nginx, ces conditions simples de « retour immédiat » sont couramment employées en production. Pour une approche plus stricte, on peut utiliser limit_except.

\n

Conclusion\u202f: « autoriser uniquement ce qui est nécessaire » simplifie la gestion

En résumé\u202f:

\n
• Les méthodes inconnues sont rarement du trafic légitime
\n
• Les faire passer à l’application engendre des coûts et pollue les logs
\n
• Bloquer au niveau de Nginx avec 405 ou 444 est la solution la plus propre
\n

En appliquant simplement ce modèle\u202f:

\n
• Moins de ressources consommées par l’application
\n
• Logs plus lisibles
\n
• Gestion opérationnelle plus fluide
\n