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

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

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

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 {#sec-7f5126fc3fdf}

`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 {#sec-84ef31ae1a20}

![Nginx as a security guard managing the entrance](/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png)

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? {#sec-967ed2222242}

There are two main ways to block.

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

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

### 2) 444 (Nginx‑only: close connection without response) {#sec-fe4e18cb7c1d}

* 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” {#sec-3c7629273a8a}

Below examples are ready to copy‑paste.

### Pattern A) Default GET/HEAD, API Adds More {#sec-42bc13636133}

```nginx
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) {#sec-fa0b2940f799}

```nginx
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 {#sec-35fe67d750b5}

The takeaway is simple.

* Strange methods are rarely legitimate traffic
* 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