# 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.

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

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 ?**
La 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 ? {#sec-b5d4f5f6dfc2}

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.

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

En revanche, bloquer avec Nginx :

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

En une phrase :

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

---

## Les méthodes étranges dans les logs sont rarement du trafic normal {#sec-7f5126fc3fdf}

`PROPFIND` est un exemple typique.

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

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.**
Il n’est donc pas nécessaire d’envoyer la requête à l’application pour y répondre poliment.

---

## Stratégie simple : opérer avec une liste blanche {#sec-84ef31ae1a20}

![Illustration d’un agent de sécurité Nginx gérant l’accès](/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png)

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

* Pages web/statiques : généralement `GET` et `HEAD` suffisent
* API : autoriser `POST/PUT/PATCH/DELETE` uniquement sur les endpoints requis

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

---

## 405 vs 444 : quelle réponse choisir ? {#sec-967ed2222242}

Il existe deux approches principales pour bloquer.

### 1) 405 Method Not Allowed {#sec-c79f33550d87}

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

### 2) 444 (Nginx : fermeture de la connexion sans réponse) {#sec-fe4e18cb7c1d}

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

En pratique, on combine les deux :

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

---

## Exemple de configuration Nginx : deux modèles pour « autoriser uniquement les méthodes » {#sec-3c7629273a8a}

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

### Modèle A : GET/HEAD par défaut, API avec méthodes supplémentaires {#sec-42bc13636133}

```nginx
server {
    # ... listen/server_name etc ...

    # 1) Par défaut : web/statics ne permettent que GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # ou 405
        proxy_pass http://app;
    }

    # 2) API : autoriser uniquement les méthodes nécessaires
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
```

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

### Modèle B : bloquer explicitement les méthodes « étranges » (début léger) {#sec-fa0b2940f799}

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

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

> Note : 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`.

---

## Conclusion : « autoriser uniquement ce qui est nécessaire » simplifie la gestion {#sec-35fe67d750b5}

En résumé :

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

En appliquant simplement ce modèle :

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