# Solo permite los métodos HTTP autorizados: corta las peticiones ruidosas con 405/444 en Nginx

Al monitorear los logs de una aplicación web en producción, a veces aparece algo inesperado.

* Pensaba que solo usaba `GET / POST / PUT / DELETE`
* En los logs aparece un método que nunca había visto

Por ejemplo, `PROPFIND`, un método WebDAV, aparece en el registro. La aplicación lo tratará como “método no soportado”, pero lo importante es:

**¿Realmente necesitamos que una aplicación que ya hace su trabajo maneje peticiones ruidosas?** La respuesta suele ser “no”. Por eso es limpio **permitir solo los métodos autorizados y cortar el resto en Nginx**.

---

## ¿Por qué bloquearlo en Nginx? {#sec-b5d4f5f6dfc2}

Se puede hacer a nivel de aplicación, pero cuando la petición llega a la app ya se incurre en costos.

* Entrada a WSGI/ASGI
* Middleware, logging, autenticación se ejecutan parcialmente
* Los logs de la app se ensucian y ocultan problemas reales
* Con mucho tráfico, el sobrecosto se acumula

Al bloquearlo en Nginx:

* **Cierre inmediato en la capa más externa** → mínimo costo
* **Logs de la app más limpios** → más fácil operación
* **Superficie de ataque reducida** → se eliminan métodos innecesarios

En una frase:

> **La app crea el producto, Nginx actúa como guardia**.

---

## Los métodos extraños en los logs suelen ser “no tráfico normal” {#sec-7f5126fc3fdf}

`PROPFIND` es un caso típico.

* Escaneo rápido para ver si WebDAV está habilitado
* Si `PUT/MKCOL` está abierto, intentan avanzar al siguiente nivel
* A veces el User‑Agent está vacío o se envía con HTTP/1.0 de forma improvisada

El punto clave es:

**Si nuestro servicio no usa ese método, es casi seguro que no sea tráfico legítimo**. No tiene sentido enviarlo a la app y responder amablemente.

---

## La estrategia es simple: operar con una lista blanca (Allowlist) {#sec-84ef31ae1a20}

![Imagen de un guardia de seguridad de Nginx gestionando la entrada](/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png)

El principio es “abrir solo lo necesario y cerrar el resto”.

* Páginas web estáticas: normalmente `GET` y `HEAD` son suficientes
* API: permitir `POST/PUT/PATCH/DELETE` solo en los endpoints que lo requieran

Y cualquier otro método (por ejemplo, `PROPFIND`, `MKCOL`, `LOCK`) que no usemos, **bloqueamos**. Es la forma más sencilla de operar.

---

## 405 vs 444: ¿qué respuesta usar? {#sec-967ed2222242}

Hay dos formas principales de bloquear.

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

* Estándar y fácil de entender
* Informa claramente a un cliente legítimo que el método no está permitido

### 2) 444 (solo de Nginx: cerrar la conexión sin respuesta) {#sec-fe4e18cb7c1d}

* Cierra sin decir nada
* Da menos pistas a escáneres/bots
* Operativamente silencioso y limpio (“ocultamos el ruido”)

En la práctica se suele combinar:

* **Métodos sin sentido en la web pública**: 444
* **Clientes legítimos que pueden cometer errores**: 405

---

## Ejemplo de configuración de Nginx: “cortar fuera de los métodos permitidos” – 2 patrones {#sec-3c7629273a8a}

A continuación se presentan ejemplos listos para copiar y pegar.

### Patrón A) GET/HEAD por defecto, API con métodos adicionales {#sec-42bc13636133}

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

    # 1) Por defecto: web/estáticos solo GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # o 405
        proxy_pass http://app;
    }

    # 2) API: solo los métodos necesarios
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
```

* `/` suele ser suficiente con `GET/HEAD` para la visualización de páginas.
* `/api/` necesita `OPTIONS` por CORS.

### Patrón B) Bloquear explícitamente “métodos extraños” (inicio ligero) {#sec-fa0b2940f799}

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

* Elimina los métodos ruidosos que vemos en producción.
* A largo plazo, el **patrón A (Allowlist)** es más seguro y fácil de mantener.

> Nota: aunque `if` en Nginx puede ser peligroso si se abusa, en este caso de “retorno inmediato” es bastante común. Si prefieres algo más estricto, puedes usar `limit_except`.

---

## Conclusión: “solo permite lo autorizado” simplifica la operación {#sec-35fe67d750b5}

El mensaje es claro.

* Los métodos extraños casi nunca son tráfico legítimo
* Enviarlos a la app genera costos y ensucia los logs
* **Por eso, en Nginx, deja pasar solo los métodos permitidos y corta el resto con 405/444**

Aplicar este patrón trae:

* Menos consumo de recursos en la app
* Logs más limpios
* Operación más sencilla