A new HTTP method just became an internet standard. The method is well specified; the surrounding security assumptions are the part that need a second look.

TL;DR

  • IETF published RFC 10008 in June 2026, defining QUERY — an HTTP method that is safe and idempotent like GET, but carries request content like POST.
  • Older WAF, proxy, framework, and load-balancer policies may not recognize QUERY yet. Some stacks will reject it; others may route or inspect it differently than POST.
  • QUERY is explicitly cacheable, and the cache key must include the request body. Caches that hash or normalize that body incorrectly open the door to cache poisoning and cache deception.
  • QUERY is not a CORS-safelisted method, so browser JavaScript must use a preflight. Test how your actual edge and application stack handles the resulting OPTIONS flow.
  • A ready-to-use Sigma-style detection rule and a stack review checklist are included below.

Why This Matters to You

If you run a WAF, an API gateway, a CDN, or CSRF middleware, you probably have policies written in terms of specific HTTP methods — usually GET, POST, PUT, DELETE, and PATCH. RFC 10008 adds a newly standardized method that behaves like a hybrid of GET and POST, and method allowlists written before June 2026 may not mention it.

That gap matters for two different audiences. Penetration testers get a fresh request type worth testing against filters tuned for the usual suspects. Defenders get a concrete review item: confirm whether rule sets, cache configurations, and CSRF libraries treat QUERY deliberately instead of accidentally.

Table of Contents

What Is the QUERY Method?

RFC 10008, authored by Julian Reschke, James M. Snell, and Mike Bishop under IETF’s HTTP Working Group, was published in June 2026 as a Proposed Standard. It defines QUERY as a method that is:

  • Safe — the client does not request or expect a state change to the target resource, same semantic model as GET.
  • Idempotent — repeating the same request produces the same result, so clients and proxies can retry it automatically without risk.
  • Cacheable — responses can be stored and reused, same as GET.
  • Body-carrying — unlike GET, the actual query lives in the request body, not the URL.

A basic 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 accept for QUERY through a new response header, Accept-Query. The RFC’s examples include application/x-www-form-urlencoded, application/sql, application/jsonpath, and application/xslt+xml — QUERY is deliberately format-agnostic, so a search backend, a GraphQL-style API, or a SQL-like filtering endpoint can all use it the same way.

Why HTTP Needed This

HTTP has had this gap since the beginning. GET is safe, idempotent, and cacheable — but the query has to fit in the URL, and practical URI limits depend on every browser, server, proxy, and gateway in the path. RFC 9110 recommends support for request targets of at least 8,000 octets, but many real deployments still have tighter or inconsistent limits. Complex searches (multi-field filters, GraphQL-style queries, Elasticsearch-style boolean logic) frequently don’t fit comfortably in a URI.

The workaround developers reached for was POST. It avoids URI-length constraints by moving the query into the request body, but it comes with the wrong semantics: POST is not safe, not idempotent, and is not normally cacheable for the same future request pattern as GET or QUERY. That means proxies can’t safely retry a failed POST, shared caches need special handling, and any tooling that assumes “POST = state change” treats a read-only search as if it were writing data.

PropertyGETQUERYPOST
Safe (no state change)YesYesNo guarantee
Idempotent (safe to retry)YesYesNo guarantee
CacheableYesYesNo guarantee
Carries a request bodyNoYesYes
Query size limitURL length and intermediariesRequest body limitsRequest body limits

QUERY closes that gap. That’s a genuine, useful fix — and it’s also exactly the kind of change that can create a blind spot, because every control that pattern-matches on HTTP methods now has to handle one more registered method correctly.

Red Team: How QUERY Can Be Abused

None of the following requires a bug in RFC 10008 itself. The risk comes entirely from how slowly the surrounding ecosystem — WAF rule sets, cache layers, CSRF middleware, load balancers — catches up to a new method.

1. WAF and IDS Inspection Gaps

Many security policies are still written around a familiar method set. Early framework discussion around the RFC already shows one practical failure mode: Rails’ Action Pack currently rejects QUERY before a controller sees it unless framework support is added. Other components may behave differently depending on whether they validate method allowlists, forward unknown methods, or inspect request bodies for unfamiliar verbs.

Neither accidental behavior is ideal. Silently dropping or ignoring the body means the rest of the stack never sees the payload it was supposed to inspect. Blanket rejection may be acceptable as an explicit temporary policy, but it should be a conscious compatibility decision rather than an unreviewed default.

Test it directly against a target that supports QUERY:

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

If the response looks like a normal application response rather than a 405 Method Not Allowed or 501 Not Implemented, something in the stack accepted the method. Compare that against how the same payload is handled over POST — if the WAF blocks the POST version but not the QUERY version, you’ve found a live inspection gap, not a theoretical one.

2. Cache Poisoning and Cache Deception

QUERY responses are explicitly cacheable, and the RFC’s guidance is that the cache key must include the request body — not just the URL. This is a hard problem: the simplest safe approach is a byte-for-byte hash of the raw body, but any cache implementation that tries to be clever (normalizing parameter order, decoding before hashing, treating semantically-equivalent bodies as identical) introduces room for mismatches between what was cached and what a given request actually asked for.

If a shared cache keys only on the URL, or normalizes the body incorrectly, an attacker can poison a cache entry other users will hit:

QUERY /search HTTP/1.1
Content-Type: application/json


{"q": "<script>evil()</script>"}

If the cache key doesn’t fully capture the body, the next legitimate QUERY /search from another user can receive the attacker’s cached, malicious response — stored XSS delivered entirely through a caching misconfiguration, with no vulnerability in the application itself.

3. CSRF Middleware Blind Spots

CSRF (Cross-Site Request Forgery) protections are almost universally scoped to “state-changing” methods — POST, PUT, DELETE, PATCH — because GET has always been assumed safe and therefore out of scope. QUERY is also marked safe by spec, which is correct in the common case. The risk shows up when a developer implements a QUERY endpoint that has a side effect it shouldn’t have — logging the query for analytics in a way that has real consequences, updating a “last searched” timestamp that feeds into rate-limiting logic, or worse. If the CSRF middleware only checks the traditional state-changing method list, a QUERY endpoint with an unintended side effect gets a free pass. If you’ve read our CSRF deep dive, this is the same class of risk as GET-based CSRF, just on a request type few teams have thought to audit yet.

4. CORS Preflight — Mostly Closed, Watch the Transition

RFC 10008’s Security Considerations explicitly address this: QUERY is not a CORS-safelisted method, so browser JavaScript must trigger a preflight OPTIONS check, same as PUT or DELETE. That’s the right call by the spec authors, and it closes the obvious “smuggle a cross-origin body past CORS because the method looks like GET” attack in conforming browser flows.

The practical risk isn’t the spec — it’s integration. Your CDN, reverse proxy, framework router, and application CORS middleware still need to handle the OPTIONS preflight and the eventual QUERY request consistently. Test the actual edge path rather than assuming that “the RFC requires it” means every component in your chain already behaves the way you expect.

5. Request Smuggling and Parser Differentials

This is the most speculative entry on this list — there’s no confirmed public case yet, so treat it as an assessed risk, not a demonstrated one. The underlying pattern is familiar from classic HTTP request smuggling: when a front-end (load balancer, CDN) and a back-end (origin server) disagree about how to parse a request, an attacker can exploit that disagreement to smuggle a second request inside the first.

QUERY is a fresh candidate for exactly this kind of disagreement, because support is still being added across frameworks and intermediaries. Some components reject the method, some pass it through, and some may inspect the request body differently from POST. If you have access to compare front-end and origin behavior directly, it’s worth checking:

Terminal window
curl -X QUERY https://target.com/ -i                                  # via front-end/CDN
curl -X QUERY https://origin-ip/ -i -H "Host: target.com"              # direct to origin, if reachable

Any divergence in how the method or body length is handled between those two responses is worth investigating further.

Blue Team: Detection and Defense

Detect Unexpected QUERY Traffic

Until QUERY is a normal, audited part of your traffic profile, treat its appearance as worth a look. A Sigma-style rule for WAF/proxy logs:

title: HTTP QUERY Method Observed
description: Flags use of the new IETF QUERY method (RFC 10008) for review while detection coverage is still maturing
detection:
  selection:
    http_method: 'QUERY'
  filter:
    src_ip|cidr: '10.0.0.0/8'   # exclude known internal API clients
  condition: selection and not filter
level: medium

Tune the filter to your own known-good QUERY clients as you adopt the method deliberately — the goal is visibility during the transition, not a permanent alert.

Stack Review Checklist

Before QUERY traffic becomes common against your applications, confirm each layer has an explicit policy for it. For body inspection and size controls, QUERY should usually receive POST-level scrutiny even though its semantics are safe:

  • WAF / IDS rules — inspection rules (SQLi, XSS, command injection) apply to the QUERY body with the same coverage as POST.
  • Cache configuration — cache keys incorporate a full hash of the request body, not just the URL and headers.
  • CSRF middleware — any endpoint that accepts QUERY and has any side effect is covered by CSRF checks, regardless of the method’s “safe” designation.
  • Load balancers / reverse proxies — confirm they neither silently strip nor ignore the QUERY body. If you choose to reject QUERY temporarily, make that an explicit policy and monitor for attempts.
  • CORS enforcement — verify browser preflight requests for QUERY reach the component that owns CORS decisions and return the expected Access-Control-Allow-Methods behavior.

What You Can Do Today

  1. Run the WAF comparison test from the Red Team section above against your own staging environment — send the same payload via POST and via QUERY and diff the results.
  2. Audit your cache layer’s key generation for any endpoint you plan to expose over QUERY — insist on full-body hashing until you’ve proven a smarter normalization scheme is safe.
  3. Grep your CSRF middleware config for its method allowlist and make sure it isn’t hardcoded to the traditional four state-changing verbs.
  4. Check your framework, CDN, reverse proxy, and WAF changelogs for QUERY support status before assuming support exists.
  5. Don’t rush to adopt QUERY in production until you’ve verified the four points above. The method itself is sound; the surrounding infrastructure is the part still catching up.

Sources