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?

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”

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)

Imagen de un guardia de seguridad de Nginx gestionando la entrada

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?

Hay dos formas principales de bloquear.

1) 405 Method Not Allowed

  • 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)

  • 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

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

Patrón A) GET/HEAD por defecto, API con métodos adicionales

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)

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

El mensaje es claro.

  • Los métodos extraños casi nunca son tráfico normal
  • 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