1

We are trying to decide the best approach to designing our new interface with our consumers. Currently we are talking about an Rest API. However there is some debate among our team about how to handle a specific situation. Currently, our consumers make a post to our service with NPI/SPI data, we take that data, gather more data and persist it to a DB. At a later point in time, users will want to retrieve that information we have gathered. Another web service will call ours (so the endpoint should never be exposed to an actual user) however we still want to hide our query parameters. It seems there are two possible ways of doing this.

  1. Encrypt our query strings (this options seems to have additional overhead on both our logic and our consumers but adhere to rest principles)
  2. Have our consumers do another POST to get the data (however this options seems to violate rest principles, but a simpler implementation)

Thus we are trying to decide the best approach. Any input?

Brian
  • 113
  • 1
  • 4

2 Answers2

4

The "hiding" issue with GET-vs-POST is logging, so yes, you want to avoid including anything in your GET URI that you wouldn't want to see saved in a logfile.

One common workaround for your problem is to use the HTTP headers to communicate information for a GET request. It's very common for credentials or session cookies, but may also be used for search strings or lookup indexes for the data you're GETting. Like the POST body, headers are generally not logged, so it's "more secure" then putting them in the GET URI.

REST is a wonderful theory. Implementing it can be disillusioning.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • I have been doing some reading on PATCH, any thoughts as to whether or not that is a good idea as an alternative to a GET? – Brian Aug 07 '19 at 03:38
  • @Brian like POST, PATCH is intended to modify (write) the server, where GET is intended to be a read operation. Having "users [...] retrieve that information we have gathered" is a read operation, not a write, so using PATCH would not be RESTful. That's my read on it... to be clear I'm not a software engineer, just a security nut who's worked on REST projects other people mang^H^H^H^Hwrote. – gowenfawr Aug 07 '19 at 12:28
2

POST query is not more secure than a GET query, they are both essentially readable content if intercepted in plain-text. It's commonly a good practice to not put sensitive data in a GET query, like username/password. Here's a good answer on the topic: Should sensitive data ever be passed in the query string?

If you want to additionally to using TLS 1.2 encrypt your communications you could use something like JWE (Json Web Ecnryption) https://www.rfc-editor.org/rfc/rfc7516

Community
  • 1
Raimonds Liepiņš
  • 994
  • 5
  • 9
  • Are you indicating that, if we use TLS1.2 having sensitive data in our query string or our post input is just as secure? – Brian Aug 06 '19 at 16:49
  • Yes, but do read up on why you shouldn't put sensitive data on the GET parameters. Usually out of convenience you would use POST, because generating a massive URL with a lot of parameters would be a pain. – Raimonds Liepiņš Aug 06 '19 at 18:28
  • I want to upvote and down vote. POST is not more secure than GET if intercepted. It is more secure than get due to the way multiple services implement logging. For the upvote however I think the JWE is a good solution to some cases. (went with upvote) – Wes Mar 11 '20 at 12:38