top of page
Search

QUERY Just Became an HTTP Method. Your WAF Rules Probably Don't Know That Yet.

Writer: Sarthak Goyal
Sarthak Goyal
Jul 16
7 min read

RFC 10008 gives HTTP a fourth "read" verb, safe, idempotent, cacheable, and finally allowed to carry a body. Here's what that actually means for the boxes sitting in front of your origin.


Illustration of an HTTP request passing through layered security inspection points, representing WAF and CDN traffic filtering

The curl command that shouldn't have worked

Picture a standard test I'd run against any new inspection rule before it ships to production: same payload, two methods, diff the output.

curl -X POST https://staging.example.com/api/search \ 
-H "Content-Type: application/x-www-form-urlencoded" \  
-d "q=' OR 1=1--"

Blocked. 403, WAF log entry, alert fires. Good.

curl -X QUERY https://staging.example.com/api/search \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "q=' OR 1=1--"

Same payload, same endpoint, different verb, and depending on how recently your rule set was updated, that second one might sail straight through. Not because the WAF is broken.

Because it was never told that this verb exists.


That verb is QUERY, and as of June 2026, it's a real, IANA-registered HTTP method, standardized in RFC 10008. I want to walk through what it is, why it exists, and, since this is the part I actually spend my days on, where it's likely to create blind spots in the very inspection and caching layers I work with.

What QUERY actually is

HTTP has had a real gap since the beginning: there was no method that was safe and idempotent and could carry a request body of any real size.


GET is safe (no server-side state changes are expected) and idempotent (repeat it as many times as you want, and you'll get the same result), but everything you want to ask for has to fit in the URL. RFC 9110 recommends that servers support request targets of at least 8,000 octets. Still, in practice, every proxy, load balancer, and framework in the chain has its own opinion about URL length, and those opinions don't always agree. A multi-field filter, a GraphQL-style query, an Elastic Search-style boolean expression, none of that fits comfortably in a query string.

So people reached for POST instead. It solves the size problem, but it comes with the wrong guarantees: not safe, not idempotent, not reliably cacheable. Which means a retry-on-timeout policy that's perfectly fine for a GET becomes dangerous for a POST, and a shared cache has to treat every POST search as a write, it can't reuse even though nothing is actually being written.

QUERY closes that gap. It's a request method that:

  • Is safe: same semantic contract as GET: the client isn't asking for a state change.

  • Is idempotent: clients and intermediaries can retry it automatically without worrying about double effects.

  • Is cacheable: responses can be stored and reused, same as GET.

  • Carries a request body: the actual query lives in the body, not the URL, so no more size gymnastics.

A minimal request looks like this:

QUERY /search HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json


status=active&created_after=2026-01-01&tags=security,pentest

Servers advertise which body formats they'll accept for QUERY via a new response header, Accept-Query. The spec's own examples list application/x-www-form-urlencoded, application/sql, application/jsonpath, and application/xslt+xml — deliberately format-agnostic, so a search endpoint, a GraphQL-style API, and a SQL-ish filter endpoint can all speak the same method.

Here's the comparison that actually matters when you're deciding what to do with it:

Property

GET

QUERY

POST

Safe (no state change)

Yes

Yes

No guarantee

Idempotent (safe to retry)

Yes

Yes

No guarantee

Cacheable

Yes

Yes

No guarantee

Carries a request body

No

Yes

Yes

Query size limit

URL length

Body limits

Body limits

The IETF's HTTP Working Group published RFC 10008 as a Proposed Standard, authored by Julian Reschke, James M. Snell, and Mike Bishop.

Why this landed on my desk, not just my RFC reading list

I don't get excited about new HTTP methods as a rule. HTTP method allowlists are one of those things everyone writes once, and nobody revisits: GET, POST, PUT, DELETE, PATCH, maybe OPTIONS, and HEAD if someone was thorough, and that's the list, forever. It shows up in WAF policy, API gateway config, CSRF middleware, and load balancer routing rules. It's boilerplate. It's also exactly the kind of boilerplate that goes stale the moment the protocol adds something new.

That's the part I care about. Not "is QUERY a good idea?" It clearly is; it fixes a real problem, but "what happens to every piece of infrastructure that currently has an opinion about HTTP methods, when a new one shows up that nobody's ruleset has ever seen?"

In a SOCC, an unrecognized method hitting an inspection layer can go one of three ways: it gets silently dropped, it gets blanket-rejected, or it gets passed through untouched because no rule matches it. None of those are wrong exactly, but only one of them is a decision anyone actually made. The other two are accidents waiting to be discovered by whoever tries it first, and it's rarely the defenders who try it first.


Where the gaps actually are


None of what follows is a flaw in RFC 10008. The spec is careful about security considerations. The risk is entirely in how slowly WAF rule sets, cache layers, CSRF middleware, and load balancers catch up to a method that didn't exist in their config six weeks ago.


1. Inspection rules built for a five-method world


If your WAF or IDS rule set matches on method name before applying payload inspection, QUERY requests may never reach the rules that would have caught them on POST. This isn't a hypothetical early framework discussion around the RFC; one concrete case has already surfaced: Ruby on Rails' Action Pack currently rejects QUERY outright unless a team has added explicit support for it. That's a defensible interim stance, but it needs to be a decision, not a default nobody checked.

Run the diff test from the top of this post against your own staging stack. If the POST version gets blocked and the QUERY version returns a normal application response, you've found a live gap, not a theoretical one.


2. Cache key correctness


QUERY is explicitly cacheable, and the spec's guidance is unambiguous: the cache key has to include the request body, not just the URL. That's a harder engineering problem than it sounds. The safe implementation is a byte-for-byte hash of the raw body. The moment a cache layer tries to be clever, normalizing parameter order, decoding before hashing, treating semantically-equivalent bodies as identical, you've opened a gap between what got cached and what a given request actually asked for.


If a shared cache keys only on the URL path (/search, say, ignoring the body entirely), one user's crafted query body can poison the cached response another user receives for the "same" URL. That's stored content-injection risk delivered entirely through a caching misconfiguration, no application vulnerability required.


3. CSRF scope written around "state-changing" methods


CSRF protection is almost universally scoped to POST, PUT, DELETE, and PATCH because GET has always been treated as out of scope, on the assumption that safe methods don't need it. QUERY is safe by spec too, which is the right default. The risk shows up when a team implements a QUERY endpoint that has a side effect; it technically shouldn't log the query in a way that has downstream consequences, or update a "last searched" timestamp that feeds rate-limiting logic. If your CSRF middleware's allowlist is the traditional four verbs, a QUERY endpoint with an unintended side effect gets a free pass by construction.


4. CORS preflight closed by spec, worth verifying by hand anyway


The RFC's Security Considerations explicitly rule QUERY out as a CORS-safelisted method, meaning browser JavaScript has to trigger an OPTIONS preflight before sending one cross-origin, the same as PUT or DELETE. That's the correct call, and it closes the obvious "smuggle a body past CORS because the method looks GET-shaped" attack for conforming browsers.

The catch is integration, not spec compliance. Your CDN, reverse proxy, framework router, and application-level CORS all need to agree on how they process that preflight and the QUERY request that follows it. "The RFC requires it" doesn't mean every hop in your chain already does it. Test the actual edge path.


What I'd tell a team shipping this today


If you're evaluating QUERY for a real endpoint, or want to know where you stand before someone else finds out for you:

  • Diff-test your inspection layer. Same payload, POST vs. QUERY, against staging. If the results differ, you have a gap to close before this becomes a production concern.

  • Audit cache key generation for anything you'll expose over QUERY. Default to full-body hashing. Don't trust a "smart" normalization scheme until you've proven it can't collide two semantically different bodies.

  • Check your CSRF middleware's method allowlist. If it's hardcoded to the traditional four verbs, that's a config change, not a redesign, but only if you go looking for it.

  • Check vendor and framework changelogs before assuming support exists. "It's an IETF standard" and "my WAF vendor shipped a rule for it" are two different facts, and the gap between them is measured in months, not days.

  • If you're not ready, reject explicitly. A deliberate 501 for QUERY while you catch up is a legitimate stance. An accidental pass-through because nothing matched.


None of this is an argument against adopting QUERY. It's a genuinely useful method that fixes a real, long-standing gap in HTTP. I'd rather see it used deliberately than see teams keep abusing POST for read-only searches because that's what the tooling already understands. The point is the same one I make every time I get called in to investigate a new endpoint that's misbehaving: new protocol capability doesn't automatically come with equivalent security coverage. That gap is measured in the time between "the RFC shipped" and "every box in your path was updated to know about it," and right now, for QUERY, that gap is wide open.


Five-step security checklist icon set for auditing HTTP QUERY method readiness across WAF, cache, and CSRF layers

Sources



Note: as of publication, QUERY support across WAF vendors, CDNs, and application frameworks is inconsistent and evolving fast. Verify current behavior against your own stack rather than assuming anything in this post is still accurate by the time you read it.

Comments

bottom of page