6

There is a system that sends POST requests from frontend to backend. These POST requests do not use the body to pass the data to the server; instead, it uses query strings in the URL params.

These requests do not send files or JSON, only several string params.

W3C does not describe that situation https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Is it a bad practice to use query strings for POST requests, and if there any negative consequences of using that from security or performance or architecture reasons?

Are there any conventions that define the usage of body or query strings for different types of requests?

Alex Borodin
  • 1,555
  • 12
  • 26
  • 1
    You can refer to this [question](https://stackoverflow.com/questions/4191593/is-it-considered-bad-practice-to-perform-http-post-without-entity-body) – Jerson Sep 24 '20 at 08:45

2 Answers2

7

Reminder: In 2014, RFC2616 was replaced by multiple RFCs (7230-7237).

Is using a query string in POST request a bad practice?

Not if you know what you are doing.

Mechanically, it is all fine: are we allowed to use POST with a target-uri that includes a query-part? Yes. Are we allowed to use POST with an empty request body? Yes. Are we allowed to do both of those things at the same time? Yes.

The hard part: will this POST request invalidate the correct representations from the cache?

Cache-invalidation happens when the server returns a non-error response to an unsafe request (POST is an unsafe request method). The representations that are invalidated are those that match the target-uri of the unsafe request.

GET /foo?a=b HTTP/2.0
POST /foo?a=b HTTP/2.0

Here, if the POST is successful, the representations cached after the successful GET request will be invalidated in the cache.

GET /foo HTTP/2.0
POST /foo?a=b HTTP/2.0

Here, the effective request-uri is not the same, which means that general purpose components won't invalidate the cached representations of /foo.

Community
  • 1
  • 1
VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
4

There's nothing wrong with using query parameters in a URL in a POST request, with or without a request body. If it makes semantic sense for your request, it's fine. The POST method in itself has a semantic meaning distinct from GET, it doesn't require a request body to be useful, and the URL is yet distinct from that again. A classic example might be:

POST /foo/bar?token=83q2fn2093c8jm203

I.e., passing some sort of token through the URL.

There's no general security problem here, since anyone who could intercept this POST request to read the URL could also read its body data; you'll hardly find an attacker in a position that allows them to read the URL but not the body. However, URLs are typically logged in server access logs and browser histories, while request bodies aren't; that may or may not be worth considering, depending on what information you're transporting in those parameters and who has access to those logs.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • 2
    There might be a security issue in case the query string contains somehow sensitive data. Request URLs tend to stay in webserver logs, request bodies usually don't. – Fiisch Sep 24 '20 at 12:00
  • Yes, as I said… – deceze Sep 24 '20 at 12:02
  • You state that `you'll hardly find an attacker in a position that allows them to read the URL but not the body` and that is true for a HTTPS-secured communication. But not in general, though. Once data get to webserver logs, they stick there for a while until they are rotated. Also nowadays, logs are usually passed to some analytics so they move around in an infrastructure and there are many potential places they can leak. On the other hand, the request body should not be logged at all, and therefore once the webserver is done processing the request, it's gone. – Fiisch Sep 24 '20 at 12:55
  • If your communication is not HTTPS secured, you should basically consider it broken outright. And yes, you're basically stating what I stated. Analytics software is a good additional explicit point, but not fundamentally different from what I already said. Unless I'm missing something?! – deceze Sep 24 '20 at 12:58
  • Hm.. I reread you post once again and yes, there is a mention at the end. Probably skipped it the first time. Apologies. :) – Fiisch Sep 24 '20 at 13:07
  • If the request initiator sits behind a VPN that logs requests, would these URLs's, even with HTTPS, also be readable for the VPN provider? – Advena Jul 29 '22 at 08:11