2

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?

3 Answers 3

6

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.

2
  • 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 7, 2019 at 3: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 7, 2019 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

3
  • 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 6, 2019 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. Aug 6, 2019 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, 2020 at 12:38
0

In addition to the ways you mentioned, here're 2 other ways to consider :

  1. Using HTTP Headers :

    In GET requests sensitive data should be transferred in an HTTP Header. Details - OWASP Security_Cheat_Sheet

  2. Secure Random UUID :

    In this method, you can use a secure-random UUID instead of the sensitive data and store a mapping of this uuid and data in the database. In most cases, it'd be safe to pass this uuid in the query param and when needed, server can get the actual data using this UUID.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .