---

title: Path Allowlists description: Exempt specific paths from method blocking — for GraphQL, search, and other POST-as-read endpoints. group: Configuration order: 2

Path Allowlists

Some APIs use POST for reads. GraphQL is the canonical case — every query and mutation is a POST to a single endpoint. Method blocking breaks these by default. The path allowlist is the escape hatch: matching path prefixes are exempt from the method block.

How it works

The allowlist is a list of path prefixes. A request whose path (the part after the upstream slug) starts with an allowlisted entry is forwarded regardless of method — the method block isn't even evaluated.

POST /graphql         → allowlisted → 200 (passes through)
GET  /api/v1/users    → not allowlisted, GET is allowed → 200
POST /api/v1/users    → not allowlisted, POST blocked → 403
DELETE /api/v1/users  → not allowlisted, DELETE blocked → 403

Configuring the allowlist

In the dashboard

1. Go to Upstreams and click Edit.
2. In Path allowlist, enter comma-separated prefixes, e.g. /graphql, /api/search.
3. Save.

Via the API

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

{ "pathAllowlist": ["/graphql", "/api/search"] }

Each entry must start with / and match /^\/[A-Za-z0-9_./-]*$/.

Matching is a prefix match

Allowlist entries match on the remaining path (after the upstream slug), as a prefix. Trailing slashes are normalized, so /api/search matches both /api/search and /api/search/anything.

This is why you should keep entries as specific as possible:

• /graphql — good.
• /api/search — good.
• /api — too broad. It would open POST, PUT, and DELETE on every path under /api.

⚠️ The allowlist bypasses ALL methods

This is the most important sharp edge. The allowlist doesn't selectively allow POST — it allows every method on matching paths. If /graphql is allowlisted, a DELETE to /graphql will also pass through.

GuardProxy can't inspect a GraphQL request body to distinguish a query (read) from a mutation (write). That would require parsing the schema and reasoning about each operation's intent — that's an application-layer concern, not a proxy's job.

If you need to block mutations on a GraphQL endpoint, run two upstreams for the same API:

• One with /graphql allowlisted — for tools that need to query.
• One without — for strict read-only enforcement.

Best practices

• Be specific. Prefer narrow prefixes (/graphql) over broad ones (/api).
• Opt in deliberately. Adding a path to the allowlist is an explicit decision to trust it with write methods. Document why.
• Review periodically. When someone asks why a write went through, the answer should be traceable to an allowlist entry you can name.