Allow Only Permitted HTTP Methods: Cut Noise Requests with 405/444 in Nginx

While tailing the logs of a running web application, you might run into moments like these.

  • I thought I was only using GET / POST / PUT / DELETE
  • The logs show a method I’ve never seen before

For example, you might see a WebDAV method like PROPFIND. The app will likely treat it as an unsupported method, but the real issue is:

Do we really need to make a production-hardened application handle noise? The answer is usually “no.” So it’s cleaner to allow only the methods you need and drop everything else at the edge with Nginx.

Why Block at Nginx?

You could block at the application level, but by the time a request reaches the app, cost has already been incurred.

  • WSGI/ASGI entry
  • Some middleware, logging, or authentication logic runs
  • The app log gets cluttered, hiding real issues
  • With high traffic, unnecessary load accumulates

Blocking at Nginx gives:

  • Immediate termination at the very front → minimal cost
  • Cleaner app logs → easier operations
  • Reduced attack surface → remove unwanted methods entirely

In one sentence:

The app builds the product; Nginx acts as the gatekeeper.

Strange Methods in Logs Are Usually Not Legitimate Traffic

PROPFIND and similar DAV methods are typical examples.

  • Scanning to see if WebDAV is enabled
  • If a misconfiguration leaves PUT/MKCOL open, attempts to move forward
  • User‑Agent may be empty or a rough pattern like HTTP/1.0

The key point is:

If our service never uses that method, it’s almost certainly not legitimate traffic. So there’s no need to send it to the app and respond politely.

The Strategy Is Simple: Operate with an Allowlist

Nginx as a security guard managing the entrance

The principle is “open only what’s necessary, close everything else.”

  • General web pages/static resources: usually just GET and HEAD
  • APIs: restrict POST/PUT/PATCH/DELETE to the endpoints that need them

All other methods (e.g., PROPFIND, MKCOL, LOCK) should be blocked if we don’t use them. This is the most operationally convenient approach.

405 vs 444: Which Response to Use?

There are two main ways to block.

1) 405 Method Not Allowed

  • Standard and easy to understand
  • Clearly tells a legitimate client that the method is not allowed

2) 444 (Nginx‑only: close connection without response)

  • Silently drops the connection
  • Gives scanners/bots less information
  • Quiet and tidy from an ops perspective (“hide the noise”)

In practice, we often do:

  • Public web: use 444 for meaningless methods
  • Legitimate clients that might err: use 405 for clarity

Nginx Configuration Example: Two Patterns for “Allow Only Specified Methods”

Below examples are ready to copy‑paste.

Pattern A) Default GET/HEAD, API Adds More

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

    # 1) Default: web/static only GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # or 405
        proxy_pass http://app;
    }

    # 2) API: allow only required methods
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
  • / is usually page‑view centric, so GET/HEAD is often enough.
  • /api/ may need OPTIONS for CORS.

Pattern B) Explicitly Block “Strange” Methods (Lightweight Start)

location / {
    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }
    proxy_pass http://app;
}
  • Cuts out the noise methods you see right away.
  • Long‑term, the Allowlist approach (Pattern A) is safer and easier to manage.

Note: While if is often warned against in Nginx, simple “immediate return” conditions are common in practice. For stricter control, you can use limit_except.

Conclusion: “Allow Only What’s Needed” Simplifies Operations

The takeaway is simple.

  • Strange methods are rarely legitimate.
  • Sending them to the app incurs cost and pollutes logs
  • Therefore, keep only the allowed methods and cut the rest with 405/444 at Nginx

Applying just this pattern:

  • Reduces app resource usage
  • Keeps logs clean
  • Makes operations smoother