For nearly three decades, the HTTP protocol has relied on a familiar set of request methods GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS. Developers and security professionals have built applications, APIs, Web Application Firewalls (WAFs), proxies, and security tools around these methods. However, a significant change has arrived. In June 2026, the Internet Engineering Task Force (IETF) officially standardized the HTTP QUERY method through RFC 10008. While this may initially appear to be just another HTTP method, it addresses a limitation that has existed since the early days of the web: the inability to send a request body with a safe and idempotent operation.
For software developers, QUERY provides a cleaner and more semantically correct way to perform complex searches. For cybersecurity professionals, however, it introduces an entirely new request type that must be understood, tested, monitored, and secured.
History has shown that whenever HTTP evolves, security tools, reverse proxies, caches, and applications require time to catch up. During that transition period, new attack surfaces often emerge. In this article, we’ll explore what the HTTP QUERY method is, why it was introduced, and, most importantly, what it means from a cybersecurity and penetration testing perspective.
Why Was a New HTTP Method Needed?
To understand QUERY, we first need to understand the limitations of existing methods.
GET Method:
GET is designed to retrieve information without changing server state. Because it is safe and idempotent, browsers, proxies, and CDNs understand how to cache and optimize GET requests. However, GET has one major limitation that it doesn’t have a standardized request body. Although some servers technically accept bodies on GET requests, many intermediaries ignore or reject them because the HTTP specification never defined a clear meaning for a GET request body.
As a result, developers often encode complex search criteria into long URLs. For simple searches this works well. For advanced filtering, it quickly becomes difficult to manage.
POST Method:
To avoid URL length limitations, many APIs switched to POST.
POST /search
{
"category":"laptops",
"brand":"Dell",
"price":{
"min":1000,
"max":2000
}
}While this solves the request body problem, it creates another issue. POST generally represents an operation that changes server state. Searching for products obviously doesn’t create or modify data, yet APIs have been forced to misuse POST simply because GET couldn’t carry structured payloads. This has been especially common in:
- GraphQL
- Elasticsearch
- Search APIs
- Analytics platforms
- Reporting systems
- Large enterprise APIs
The QUERY method fills this gap.
What is the HTTP QUERY Method?
The QUERY method is a new HTTP request method standardized in RFC 10008. It allows clients to send structured request bodies while maintaining the semantics of a safe and idempotent operation. In simple terms QUERY is designed for read-only operations that require a request body.
Example:
QUERY /products
{
"category":"Laptop",
"brand":"Dell",
"price":{
"min":1000,
"max":2000
},
"availability":"InStock"
}The request body can contain complex search filters without abusing POST.
Why This Matters for Cybersecurity
From a security perspective, QUERY is much more than another HTTP verb. Every component that processes HTTP requests must now understand and correctly handle QUERY. That includes:
- Web Application Firewalls (WAFs)
- Reverse Proxies
- API Gateways
- CDNs
- Load Balancers
- Security Monitoring Platforms
- API Frameworks
- Authentication Middleware
- Pentesting Tools
Any inconsistency between these components can become a potential security issue. Let’s examine some of the areas security professionals should pay attention to.
1. Web Application Firewall (WAF) Compatibility
Many existing WAF deployments have explicit allowlists for HTTP methods. Typical configurations permit methods such as:
- GET
- POST
- PUT
- DELETE
- PATCH
- OPTIONS
- HEAD
A QUERY request may initially be:
- Blocked outright
- Treated as an unknown method
- Logged incorrectly
- Pass through without the expected inspection if custom policies haven’t been updated
Security teams should review their WAF rules to ensure QUERY requests receive the same level of inspection as existing methods rather than assuming current configurations will automatically handle the new verb.
2. Reverse Proxies and API Gateways
Reverse proxies and API gateways are responsible for:
- Request Routing
- Authentication
- Authorization
- Caching
- Rate limiting
- Request validation
Many deployments make routing decisions based on HTTP methods.
Where does QUERY fit?
If infrastructure components haven’t been updated, inconsistent handling may occur between the gateway and the application. Whenever different layers interpret a request differently, it becomes an area worth testing during a security assessment.
3. Logging and Security Monitoring
Security Operations Centers (SOCs) rely heavily on HTTP methods for detection and investigation. Dashboards frequently categorize requests by method. During the early stages of QUERY adoption, organizations should verify:
- Is QUERY captured in web server logs?
- Does the SIEM parse it correctly?
- Do dashboards classify it properly?
- Are alerting rules affected by unknown methods?
- Can incident responders easily identify QUERY traffic?
Poor visibility can delay investigations and create blind spots.
4. API Security
Modern APIs increasingly rely on complex search functionality, GraphQL is one example. Today, many GraphQL implementations use POST even for read-only queries because GET requests cannot reliably carry large request bodies. QUERY provides a method that better reflects the intent of these operations:
QUERY /graphql
{
"query":"…"
}While adoption will take time, future API frameworks may begin supporting QUERY as a more semantically appropriate alternative for read-only operations. Security testing methodologies should evolve alongside these changes.
5. Caching Considerations
One of the key design goals of QUERY is that responses can be cacheable under appropriate conditions. Caching is excellent for performance. It can also introduce security risks if implemented incorrectly. Security testers should verify:
- Are cache keys generated correctly?
- Is user-specific data cached?
- Can cache poisoning occur?
- Do intermediaries differentiate requests with different bodies?
- Is sensitive information ever served from a shared cache?
Organizations adopting QUERY should validate cache behavior carefully during implementation.
6. Rate Limiting
Many API gateways implement rate limiting based on request methods. Example:
GET → 500 requests/minute
POST → 100 requests/minuteShould QUERY inherit the GET policy?
Should it have its own limits?
If rate-limiting policies overlook QUERY, attackers may be able to perform high-volume search operations without the intended restrictions. This is something defenders should verify as support for QUERY is introduced.
7. Security Tool Support
Security tools will gradually need to add first-class support for QUERY. These include:
- Burp Suite
- OWASP ZAP
- Postman
- curl
- Nuclei
- FFUF
- HTTPie
- API gateways
- Browser developer tools
Until support becomes widespread, testers should verify that tools preserve the QUERY method correctly and that intermediaries do not rewrite or reject it unexpectedly.
Will QUERY Introduce New Vulnerabilities?
The QUERY method itself is not inherently less secure than existing HTTP methods. The specification is designed to support safe, read-only operations and does not introduce vulnerabilities by design. However, history shows that the adoption of new protocol features is where security challenges often arise. Potential risks are more likely to stem from:
- Incomplete support in reverse proxies
- Outdated WAF configurations
- Inconsistent authorization logic
- Logging and monitoring gaps
- Caching misconfigurations
- Implementation bugs in frameworks or applications
As vendors, frameworks, and infrastructure providers add QUERY support, security teams should validate that it is handled consistently across the entire request path.
The Future of QUERY
The QUERY method is unlikely to replace GET or POST overnight. Millions of existing applications already rely on established HTTP semantics, and widespread adoption will take time. However, for APIs that perform complex, read-only searches, QUERY offers a cleaner and more expressive alternative than overloading POST or forcing large amounts of data into URLs.
As frameworks, browsers, proxies, CDNs, API gateways, and security tools adopt the new method, it has the potential to become a standard choice for sophisticated query operations. For cybersecurity professionals, understanding QUERY early provides an opportunity to stay ahead of the adoption curve and prepare testing methodologies before it becomes commonplace.
The introduction of the HTTP QUERY method marks one of the most significant additions to HTTP in years. While its primary purpose is to provide a standardized way to perform safe, idempotent requests with a request body, its impact extends far beyond application development.
Every layer of modern web infrastructure from WAFs and reverse proxies to API gateways, caches, SIEM platforms, and penetration testing tools will need to understand and correctly process this new method.
For developers, QUERY brings cleaner API design. For defenders, it introduces new considerations for visibility, policy enforcement, and monitoring. For penetration testers and bug bounty hunters, it represents another area to evaluate when assessing modern web applications. As with any protocol evolution, the method itself is not the security risk. The real challenge lies in ensuring that every component in the request path interprets and enforces QUERY consistently. Organizations that proactively test and validate their implementations will be better positioned to adopt the new standard securely while avoiding the pitfalls that often accompany changes in foundational web technologies.