Allow Only Permitted HTTP Methods: Block Noise Requests with 405/444 in Nginx [ r1 ]

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

While tailing logs of a running web application, you might encounter moments like these.

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

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

Do we really need to let a well‑worked application handle noise?\nThe answer is usually “no.” Therefore, it’s cleaner to allow only the methods you need and cut the rest at the front‑end 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.

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

Blocking at Nginx gives:

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

In one sentence:

\n

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

\n

Strange Methods in Logs Are Usually Not Legitimate Traffic

PROPFIND and similar DAV methods are typical examples.

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

The key point is:

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

The Strategy Is Simple: Operate with an Allowlist

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

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

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

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

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

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

In practice, we often do:

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

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 {\n    # ... listen/server_name etc ...\n\n    # 1) Default: web/static only GET/HEAD\n    location / {\n        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # or 405\n        proxy_pass http://app;\n    }\n\n    # 2) API: allow only required methods\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
• / is usually page‑view centric, so GET/HEAD is often enough.
\n
• /api/ may need OPTIONS for CORS.
\n

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

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

\n
• Cuts out the noise methods you see right away.
\n
• Long‑term, the Allowlist approach (Pattern A) is safer and easier to manage.
\n

\n

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.

\n

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

The takeaway is simple.

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

Applying just this pattern:

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