The introduction of the HTTP QUERY method through RFC 10008 in June 2026 highlights an important cybersecurity challenge: internet protocols continue to evolve, but the security controls protecting web applications may not evolve at the same pace. QUERY introduces a standardised way to submit complex queries in an HTTP request body while preserving safe and idempotent behaviour, combining some characteristics traditionally associated with GET and POST. Although the method provides legitimate benefits for developers and API designers, it also creates potential security gaps in web application firewalls, API gateways, caching infrastructure and application frameworks that were designed around an established set of HTTP methods. The concern is not that QUERY is inherently malicious, but that inconsistent handling across different infrastructure components may allow attackers to exploit differences between what security controls inspect and what backend applications actually process.

Traditionally, GET has been used to retrieve information, with search parameters frequently placed in the URL, while POST commonly carries information in the request body and may be used for operations that modify application state. QUERY provides an alternative for complex searches that cannot conveniently be expressed within a URL. It allows the query parameters to be placed in the request body while defining the operation as safe and idempotent, meaning that the request is not intended to change the target resource's state and can be repeated without introducing additional state changes. The specification also permits caching of QUERY responses, provided that the cache correctly incorporates the request content and relevant metadata into its cache key. This flexibility is useful for legitimate applications, but it requires every component along the request path to understand how the method should be processed. 

The most immediate security concern involves web application firewalls that apply different inspection logic according to the HTTP method. Many WAF deployments include rules designed to identify SQL injection, cross-site scripting, command injection and other malicious patterns within request parameters and bodies. If those rules explicitly associate body inspection with POST requests, a QUERY request containing the same malicious payload could potentially pass through a less restrictive inspection path. The backend application may accept the QUERY request and process its body normally, creating a mismatch between the security layer and the application it protects. This is a potential inspection bypass arising from inconsistent implementation rather than an intrinsic vulnerability in the HTTP QUERY standard. 

The risk becomes clearer when considering applications that expose search functionality through multiple methods. An organisation may have carefully configured its WAF to inspect search parameters supplied through GET URLs and POST bodies, but a newly introduced QUERY endpoint might not automatically inherit the same protections. If the API gateway accepts the method while the WAF fails to parse its body, malicious input could reach the application without receiving equivalent inspection. The underlying application must still contain a vulnerability for an injection attack to succeed, so accepting QUERY does not itself create SQL injection or remote code execution. Nevertheless, inconsistent inspection can remove an important defensive layer and increase exposure to existing application weaknesses. 

API gateways introduce another potential area of inconsistency. Security policies frequently rely on method allowlists that explicitly identify permitted operations for each API endpoint. A gateway might recognise GET, POST, PUT, DELETE and PATCH but have no defined policy for QUERY. Depending on its implementation, an unfamiliar method may be rejected, passed through without the intended controls or handled by a generic fallback rule. The correct behaviour depends on the application's requirements, but it should always be deliberate. Organisations that do not intend to support QUERY should reject it explicitly, while those adopting it should define clear authentication, authorisation, inspection and logging policies rather than assuming existing GET or POST rules will automatically apply. 

The SANS Internet Storm Center analysis highlights inconsistent handling among current web infrastructure. Some components reject QUERY by default, while others permit it to pass through when the relevant route or configuration supports arbitrary HTTP methods. This variation creates opportunities for unexpected behaviour in environments containing multiple proxies, load balancers, application servers and security gateways. A request might be accepted by an edge proxy but rejected by the application framework, or accepted by the backend while bypassing a method-specific rule in an intermediate security device. These differences should be identified through compatibility and security testing before enabling the method in production. 

Caching introduces a separate concern because QUERY requests may contain substantial search parameters in their bodies while targeting the same URL. Under RFC 10008, caches that support QUERY must incorporate the request content and relevant metadata into the cache key. A cache that incorrectly identifies entries using only the URL could potentially treat requests containing different query bodies as equivalent. If the cache also stores and serves the corresponding responses, one user's result could be returned to another user, creating incorrect responses or potentially exposing sensitive information. This is a conditional cache-design failure, not an unavoidable consequence of using QUERY, and correctly implemented caching must account for the request body. 

The security implications can become particularly serious when applications use query bodies to select customer-specific information, account details or other sensitive records. Two requests may target the same endpoint but contain entirely different search criteria. If an intermediary ignores those differences while caching responses, the application may produce correct results while the cache subsequently delivers them to the wrong requester. Organisations adopting QUERY should therefore verify that every cache in the request path either implements the method correctly or declines to cache its responses. Authentication-dependent and sensitive responses require particular care to prevent unintended data disclosure. 

Cross-site request forgery protections also require attention because some middleware implementations classify requests according to traditional HTTP methods. QUERY is defined as a safe method, meaning an application should not use it to perform unintended state-changing operations. However, legacy applications sometimes contain endpoints that produce side effects even when the HTTP method suggests otherwise. If an application accepts QUERY for such an endpoint while CSRF middleware ignores the request because it is considered safe or unrecognised, a security gap may arise. This scenario depends on incorrect application semantics and inadequate middleware handling rather than QUERY itself. Developers should ensure that operations modifying application state use appropriate methods and that authorisation and CSRF protections are applied consistently. 

Browser security provides an additional distinction. QUERY is not a CORS-safelisted method, so cross-origin browser requests require a preflight request. This creates an opportunity for servers to enforce explicit cross-origin permissions, but organisations should not rely on CORS alone as an authentication or authorisation mechanism. Non-browser clients are not constrained by browser CORS enforcement, and a malicious actor can construct QUERY requests using command-line tools or custom applications. Consequently, backend security must validate the request independently of browser behaviour. 

The introduction of QUERY also has implications for security monitoring and incident investigation. Many access logs record the HTTP method, URL, response code and other request metadata but do not capture request bodies. Because QUERY places its search content in the body rather than the URL, logging systems that previously relied on URL parameters may lose visibility into the information being submitted. This could make it more difficult to reconstruct suspicious API activity, identify injection attempts or correlate requests with application errors. Organisations should review their logging strategy to ensure that QUERY traffic is appropriately classified and monitored while avoiding indiscriminate recording of sensitive request bodies. 

From a malware and command-and-control perspective, the new method should not automatically defeat behavioural detection. Network analytics based on connection frequency, beaconing intervals, traffic volumes and communication patterns operate independently of the HTTP method. TLS fingerprints and related connection-level indicators are similarly unaffected by whether a request uses GET, POST or QUERY. However, a security product that relies specifically on identifying POST requests to detect suspicious request bodies may require updates. Furthermore, when HTTPS traffic is not decrypted, a network security device cannot normally inspect the HTTP method inside the encrypted connection in the first place. These distinctions are important because they show that the security implications depend on the visibility and detection mechanisms actually deployed. 

For next-generation firewalls and intrusion prevention systems, the arrival of QUERY creates a clear requirement to review HTTP parsing and policy enforcement. Protocol-aware inspection should recognise the method, identify the presence of a request body and apply relevant detection rules according to the content and context of the request. Security policies should not assume that malicious input will appear only in traditional POST bodies or GET parameters. At the same time, unsupported methods should be handled predictably, with explicit allow or deny behaviour rather than silently passing through incomplete inspection paths. 

Application developers should evaluate whether QUERY provides a genuine operational benefit before enabling it. Organisations with complex search APIs may find the method useful because it supports structured search bodies, safe semantics and standards-based caching. However, adoption should be accompanied by coordinated changes across the entire request-processing chain, including the application framework, reverse proxy, WAF, API gateway, caching layer and logging infrastructure. Testing only the backend application is insufficient if an intermediate component interprets the method differently. 

A practical security assessment should include sending equivalent authorised test requests using supported methods and verifying that the expected security controls behave consistently. Organisations should confirm that QUERY bodies are parsed correctly, malformed input is rejected, access-control rules remain effective, caching separates requests with different bodies and unsupported endpoints return appropriate errors. Tests should also examine oversized bodies, unusual content types, encoded payloads and discrepancies between frontend and backend interpretations. Such testing can expose inconsistencies before attackers discover them. 

The broader lesson is that security policies built around fixed assumptions about protocols eventually become outdated. HTTP has evolved through new transport versions, headers, authentication mechanisms and application patterns, and the introduction of QUERY adds another behaviour that infrastructure must interpret correctly. Security products and applications that rely on simplistic method matching may struggle when the protocol introduces new combinations of familiar characteristics. Effective security therefore requires standards-aware parsing, consistent policy enforcement and continuous compatibility testing rather than assuming that every request will fit an established GET-or-POST model. 

Ultimately, HTTP QUERY is a legitimate standards-based development that can improve the design of complex read-only APIs. Its introduction is not evidence of an active exploit campaign or proof that existing WAFs are universally vulnerable. The real concern is the possibility of inconsistent support across the different systems responsible for receiving, inspecting, forwarding, caching and processing HTTP traffic. Organisations should update method-aware security policies, inspect request bodies consistently, verify cache behaviour, review API access controls and ensure that unsupported methods are rejected deliberately.

In June 2026 the IETF published RFC 10008[1], defining a new HTTP method: "QUERY". The HTTP protocol faced already by changes (HTTP/2, HTTP/2) but it's the first new standard HTTP verb since "PATCH" in 2010!

Source: HTTP QUERY Method: The Grey Zone Between GET And POST., (Fri, Sep 18th) via SANS Internet Storm Center — published 18 Sep 2026.