Are You Leaking User Information in Your GET Requests?
Here at Wildebeest, I’m typically working on the backend in some capacity, which means that I’m writing an API endpoint at least once, if not several times a week. As a developer it can be easy to fall into a routine or become over confident when you’ve done a similar task a few times before. However, this mindset can ultimately lead to poor code, or in this case, a potential security risk.
The Problem: Based off of a callback coming from the Slack API, I need to retrieve a user’s account using only their email address.
The Solution: Write a GET request with the user’s email address as a URL query string.
So, something like this?
GET https://api.wildebee.st/account/janedoe@wildebee.st
That should work.
But wait, is it okay to send a GET request with a user’s email address?
Maybe? Probably not.
Would it be okay to send a GET request if I hashed the email address first?
No, that’s still pretty much sending their email.
What if I turn it into a POST request?
That could work, but you’re really doing a GET, not a POST.
“What’s wrong with exposing a user’s email address,” you might ask?
If your website deals with anything people might not want others to know they’re associated (a disease perhaps), they won’t be very happy that their email is public. Or, while unlikely, imagine a scenario where a user’s email address is HI_IM_JOHN_DOE_WITH_X_DISEASE@foo.com.
Stumped on what the best practice was for this scenario, I turned to every developer’s saviors, Google and Stack Overflow.
After reading several Stack Overflow posts and even a few blog posts on this similar topic, I learned a few things:
- Doing a GET request with an email query string isn’t necessarily taboo, but it’s probably not the best practice if it can be avoided.
- Sending any kind of sensitive information over HTTP is a bad idea. Data sent over HTTP is more or less sent in plain text and anyone along the way can view what is being sent. (Here at Wildebee.st, we use Let’s Encrypt.)
- Even doing a GET request with url query strings over HTTPS can lead to potential privacy concerns despite information being encrypted before being sent. Specifically, GET requests are often logged in plain text on server logs.
If your company or project is dealing with any kind of patient health data you should definitely avoid displaying or sharing users’ email addresses unnecessarily. If you find yourself in such a situation, I recommend either sending the emails in the headers of the request, or changing your request to a POST if absolutely necessary. Keep in mind that even request headers can be viewed or cached in the browser history if someone really wants to see.
As for my original problem, although the project didn’t involve any kind of patient health data, I ultimately decided on still sending a GET request but attaching the user’s email address in the request headers rather than in the query string, thinking it was best not to unnecessarily show a user’s email in our server logs. If you’re still interested in reading more about this topic, I recommend reading this blog post from Full Contact.
This article was written by Mike Woo, a software developer at Wildebeest. His favorite animal is the capybara.
Icon made by Freepik from www.flaticon.com
