HTTP QUERY Method: From the RFC to the Cybersecurity Lab

It all began in 2015 with the publication of the draft-snell-search-method-00 [1]. The proposal sought to revisit the SEARCH method, originally defined in RFC 5323 for WebDAV [2], and turn it into a more suitable alternative for HTTP queries that need to send information in the request body. The idea was not to replace GET or POST, but to fill a gap between the two: enabling complex queries with content in the request body, as it is often done with POST, without giving up important properties associated with read operations. 

In the proposal, SEARCH was safe and idempotent. Safe means the operation is not intended to alter the state of the resource, since it is a query rather than a modification operation. Idempotent, in turn, means that repeating the same request does not produce additional effects on the server state. It is like pressing the elevator button several times: it may ease your anxiety, but it shouldn’t summon multiple elevators. 

Five years later, in 2020, engineers Tommy Pauly and Mark Nottingham opened the Call for Adoption: SEARCH Method [3].  The discussion consolidated interest in standardising a method that combined the read semantics of GET with the ability to carry the query in the request body. In 2021, the method received a more representative name, QUERY [4], and continued to be refined until the publication of RFC 10008 - The HTTP Query Method - in June 2026 [5]. 

RFC 10008 defines QUERY as a safe, idempotent method with cacheable responses, designed specifically for queries whose content can be sent in the request body. Caching makes it possible to store a response and reuse it for an equivalent query, avoiding unnecessary processing. In this case, however, the cache key cannot depend solely on the URI: it must also incorporate the request content and related metadata. 

The use of QUERY can also contribute to more organised logging and facilitate application behaviour analysis. For example, an application might record 100 GET requests, 10 POST requests, and 450 QUERY requests. Without QUERY, those 450 queries could be performed using POST, resulting in a total of 460 POST requests, even though only 10 would be related to modification operations. Separating queries from other operations in logs helps provide a clearer understanding of normal application usage and can facilitate the identification of anomalous behaviour.  

By allowing query parameters to be sent in the request body, QUERY also reduces the amount of potentially sensitive information exposed in the URI. This distinction matters because URIs tend to leave a long trail across the infrastructure: they may appear in server and proxy logs, observability tools, browser histories, and monitoring systems. The request body, on the other hand, tends to have more controlled exposure. As a result, query data is less exposed and, when it contains sensitive information, is less likely to appear in logs and other records along the way. 

I first learned about QUERY through my advisors, who introduced me not only to RFC 10008 but also to a number of questions that remained relatively unexplored: how would this method behave in forms? To what extent would browsers recognise it? How would the Same-Origin Policy (SOP) apply? Would the restrictions imposed by WAFs also cover this new method? And this is how QUERY earned itself a one-way ticket to the cybersecurity lab. 

In tests with Chrome [6], Edge [7], and Firefox [8], QUERY encountered its first obstacle in HTML forms. When QUERY was used as the value of the method attribute, all three browsers submitted the request as GET. This behaviour is consistent with the HTML Standard, which currently recognises GET, POST, and DIALOG and defines GET as the default state for invalid method values. From a security perspective, this limitation is significant, since forms are one of the simplest mechanisms for triggering cross-origin requests and have historically played an important role in attacks such as CSRF. 

With fetch and XMLHttpRequest (XHR), the scenario was different: all three browsers preserved the QUERY method. Its use also respected the SOP, a security model that isolates content from different origins and restricts interactions between them [9]. Because QUERY is not a part of the set of CORS-safelisted methods, cross-origin requests required a preflight, meaning that the server had to authorise the method before the actual request could be sent. This raises an interesting question: if QUERY was specifically designed for queries and is defined as a safe method, why is it not part of the CORS safelist? Before its introduction, queries of this kind were already performed using GET or POST, both of which are CORS-safelisted. Although safe and CORS-safelisted are distinct concepts, the difference in treatment is relevant when considering the adoption of a new method. Thus, QUERY has browser support, but remains subject to the same origin boundaries that structure security on the Web. 

The introduction of QUERY also did not change how SameSite cookie policies were enforced. Across all three browsers, cookies configured with SameSite=Strict, SameSite=Lax, and SameSite=None followed the expected restrictions according to the requested context. Strict restricted cookies to same-site contexts, while None, when accompanied by Secure, also allowed them to be sent in cross-site contexts. For Lax, the established exception for top-level navigation performed with safe methods remains in place [10]. The results therefore indicate that the introduction of QUERY does not bypass the restrictions imposed by SameSite, preserving this mechanism for mitigating cross-site requests, including in scenarios related to CSRF. 

Outside the browser, however, QUERY received a somewhat less enthusiastic welcome. In tests with ModSecurity [11] and OWASP CRS [12] using the default configuration, QUERY was treated as a method outside the policy allowed by the WAF. This happens because CRS works with a list of HTTP methods considered valid and assigns an anomaly when it encounters one outside that list. Because QUERY is not yet included, five points were added to the anomaly score, reaching the blocking threshold and preventing the request from reaching the application. In this case, adopting QUERY also means formally introducing it to the WAF. Otherwise, it ends up being stopped at the door. 

In addition to the behaviour observed in the tests, RFC 10008 defines that the Location and Content-Location headers may indicate resources associated with the query. While Content-Location can point to a resource representing the result obtained, Location can identify a resource that allows the query to be repeated using GET, without requiring the original content to be resent. This mechanism provides a way to reuse results or the query itself, but it also means that a single QUERY request may give rise to additional resources that remain accessible afterwards. Therefore, implementations must carefully consider the lifecycle and exposure of these resources.

Finally, the specification also reduces ambiguity in how the request body is interpreted: the Content-Type header must correctly indicate the format being sent, without the server resorting to content sniffing to guess it, while the Accept-Query header can be used to indicate which formats are accepted. This leaves applications and intermediaries with less room to interpret the same content differently, a scenario in which a little less creativity is very much welcome. 

Conclusion

The results show that the introduction of QUERY expands the possibilities for HTTP queries without (at least in the scenarios analysed) breaking well-established Web security mechanisms. In addition to enabling queries with content in the request body, the method can help better distinguish query operations in logs, contributing to a clearer view of application behaviour. At the same time, browsers continue to enforce SOP, CORS, and SameSite restrictions, while HTML forms do not allow QUERY to be used directly.

Whereas the experience with ModSecurity and OWASP CRS highlights an important aspect of adopting new standards: it is not enough for a method to be defined and implemented by clients and servers; the entire intermediary infrastructure must also be prepared to recognise it. Between the publication of an RFC and its effective adoption lies an entire ecosystem that needs to keep pace with the change. 

This article does not necessarily introduce anything new to the cybersecurity community. Instead, the goal was to use QUERY as a starting point to go beyond executing payloads: to understand the specification, observe how different components behave, and investigate its security implications. The code used in the experiments is available in the project repository [13]. Rather than arriving at definitive answers, the aim was to document the results and pave the way for further analysis of QUERY adoption.

References

[1]RESCHKE, Julian; MALHOTRA, Ashok; SNELL, James M. HTTP SEARCH Method. Internet-Draft: draft-snell-search-method-00. Internet Engineering Task Force (IETF), Apr. 10, 2015. Available at: https://datatracker.ietf.org/doc/html/draft-snell-search-method-00. Accessed: Aug. 26, 2026.

[2]RESCHKE, Julian et al. Web Distributed Authoring and Versioning (WebDAV) SEARCH. RFC 5323. Internet Engineering Task Force (IETF), Nov. 2008. Available at:  https://www.rfc-editor.org/rfc/rfc5323.html. Accessed: Aug. 26, 2026.

[3]BARRITEAU, Juan. Re: Call for Adoption: SEARCH method. IETF HTTP Working Group Mailing List, Apr. 4, 2021. Available at: https://lists.w3.org/Archives/Public/ietf-http-wg/2021AprJun/0016.html. Accessed: 26 ago. 2026.

[4]HTTP WORKING GROUP. What method name to use. Issue #1614, HTTP Extensions, GitHub. Available at:  https://github.com/httpwg/http-extensions/issues/1614. Accessed: Aug. 26, 2026.

[5]RESCHKE, Julian; SNELL, James M.; BISHOP, Mike. The HTTP QUERY Method. RFC 10008. Internet Engineering Task Force (IETF), June 2026. Available at: https://datatracker.ietf.org/doc/rfc10008/. Accessed: Aug. 26, 2026.

[6]GOOGLE LLC. Google Chrome: version 146.0.7680.177. [Software]. Mountain View: Google LLC, 2026.

[7]MICROSOFT CORPORATION. Microsoft Edge: version 151.0.4129.93, x86_64, for Linux. [Software]. Redmond: Microsoft Corporation, 2026.

[8]MOZILLA FOUNDATION. Mozilla Firefox ESR: version 128.3.1esr, 64 bits, for Linux. [Software]. Mountain View: Mozilla Foundation, 2024.

[9]BARTH, Adam. The Web Origin Concept. RFC 6454. Internet Engineering Task Force (IETF), Dec. 2011. Available at:  https://www.rfc-editor.org/rfc/rfc6454.html. Accessed: Aug. 26, 2026.

[10]BINGLER, Steven; WEST, Mike; WILANDER, John. Cookies: HTTP State Management Mechanism. Internet-Draft: draft-ietf-httpbis-rfc6265bis-13. Internet Engineering Task Force (IETF), Nov. 15, 2023. Available at: https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/13/. Accessed: Aug. 26, 2026.

[11]OWASP FOUNDATION. ModSecurity: version 2.9.14, Web Application Firewall (WAF). [Software]. Wakefield: OWASP Foundation, 2025.

[12]OWASP FOUNDATION. OWASP Core Rule Set (CRS): version 3.3.10, rule set for Web Application Firewalls. [Software]. Wakefield: OWASP Foundation, 2022.

[13]FIGUEIREDO, Victoria C. HTTP Query Compatibility. GitHub. Available at: https://github.com/victoriacfigueiredo/http-query-compatibility. Accessed: Aug. 26, 2026.