0

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?

1

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://tools.ietf.org/html/rfc7516

  • 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 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 6 at 18:28
1

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.

  • 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 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 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.