---

title: Blocked Methods description: How method blocking works, the defaults, and how to customize which HTTP methods are blocked per upstream. group: Configuration order: 1

Blocked Methods

Every upstream has a blocked methods list — the HTTP methods GuardProxy will reject with a 403 before they reach the upstream API. Everything else is forwarded.

The defaults

A new upstream blocks the four standard write methods:

["POST", "PUT", "PATCH", "DELETE"]

That leaves GET, HEAD, and OPTIONS passing through — exactly the methods a read-only integration needs.

Method semantics

Method	Default result	Notes
GET	✅ forwarded	reads work
HEAD	✅ forwarded
OPTIONS	✅ forwarded	always allowed (CORS preflight needs this)
POST	❌ 403	unless the path is on the allowlist
PUT	❌ 403
PATCH	❌ 403
DELETE	❌ 403

A 403 response body looks like:

{
  "error": {
    "code": "method_blocked",
    "message": "POST is blocked on this upstream"
  }
}

Treat error.code === "method_blocked" as the proxy doing its job, not an upstream error. Don't retry; don't escalate it as a bug. It means the safety net caught a write.

Customizing the list

You can block any combination of the seven standard methods. In the dashboard, open the upstream and click the method chips to toggle them on (blocked) or off (forwarded).

The path allowlist takes precedence over the method block. A request to an allowlisted path is forwarded regardless of method — see Path Allowlists.

Via the dashboard

1. Go to Upstreams and click Edit on the upstream.
2. Toggle the method chips. Blocked methods are highlighted.
3. Save.

Via the API

PATCH /api/upstreams/{id}
Content-Type: application/json

{ "blockedMethods": ["DELETE"] }

This example blocks only DELETE and forwards everything else (including POST). Methods must match GET|HEAD|OPTIONS|POST|PUT|PATCH|DELETE (case-insensitive; stored uppercase).

When to change the defaults

Most setups should leave the defaults alone — they cover the standard read/write split. You might narrow the list when:

• An API legitimately uses POST for reads (search endpoints). Prefer adding that specific path to the allowlist rather than unblocking POST globally.
• You want to test writes temporarily. Remove a method, verify, then restore it.

Keep the list as strict as your use case allows. The goal is least privilege.