Is it a security issue to include postcode and/or last name in a GET request query string?

Question

I'm currently designing an API endpoint to validate a customer, and they can either pass in their postcode or their last name, as well as their customer ID (plus some other irrelevant data).

I've heard that including PII or sensitive data in the query string can be a security risk. I can't find a whole lot of information on this, apart from not including obvious things like passwords.

This endpoint uses one query string parameter for both the postcode or last name (obviously not ideal but it's a limitation). If someone got access to the server logs, is it possible to correlate multiple requests from one user, which could result in that person being identified by combining their postcode and last name? This would be possible from looking at their browser history at least so that may be an issue.

And would it be preferable to do this validation as a POST request? I'm not sure at what point it becomes a security risk and what kind of data is safe to include in the query string, and at what point data becomes personally identifying or if that's really an issue.

Looking at popular APIs like Stripe and Shopify, it seems they do customer searches with a query string, but Salesforce does it with a POST, so not really sure which is the way to go.

Answer 1

Given the fact you are from the UK I will assume the GDPR applies to you.

And it goes like this: PII (Personally Identifiable Information) is any and all information that by itself or by combining it with another piece of information can be (potentially) traced back to a individual.

now, applying this to your situation:

• the postal code with 1 more piece of information can be traced back to a induvidual, its a PII therefor.
• the last name is a PII by default, is its part of the identifier of a natural person.

Given that we are working with PII we have the obligation to employ industry standards for privacy, security and other practices.

this means: any means that could be logged or tracked is simply not allowed. (this means no GET requests with this data in it, since they get stored in the browser and can be stored in other places).

Using a POST request would prevent most people from storing it (unintentionally). however just using POST is not sufficient, since others can still see its contents. there for we have to use modern TLS (1.3 or 1.2) protected connections (HTTPS) for transmitting and receiving these requests.

And all of this is just what the GDPR requires. It doesn't include any other requirements (legal or otherwise).

Answer 2

Hello and welcome to StackOverflow.

Let's complete other(s) answers.

It is a security issue to include any kind of valuable data in the GET query string. It could enable attackers to attack your system to steal valuable data.

When you use GET, form parameters key=values pairs are appended in response URI. It is sensitive information disclosure in the client browser URI bar.

It can also be an information disclosure in other places, like client/server logs. It is possible to configure web servers to fully log incoming HTTP requests. This, including the URI querry string.

1. An attacker can steal them with physical or remote access to the client's browser or server.
2. It can also sniff them over the network.

To prevent 2., setting up encryption is mandatory. This means that all the API endpoints must use the HTTPS protocol. This with Transport layer Security (TLS) correctly configured.

After that, to prevent 1:

In GET requests, sensitive data should stay in an HTTP Header.

In POST requests, sensitive data should stay in the request body or request headers.

The choice between GET and POST is if the web API follows a particular style, (eg. RESTful web API etc...)

Answer 3

Is it a security issue to include postcode and/or last name in a GET request query string?

Yes, in case you transmit them in plain text (i.e. not encrypted at the channel level¹ nor at the data level²).

Revealing the postcode and/or the last name of an account owner poses a risk, because they can be used to support an attack against the owner and/or the account (the last name poses a significantly higher risk than the postcode).

On top of that, there's now legislation³ that classifies those two as personal data (or PII), either directly (last name) or indirectly (postcode). Thus, you also have the legal obligation to take extra steps to protect them.

Suggestions for your API:
Assuming that your API aims to be REST(-ish) compliant (read: validation through GET does not change your system's state), and that you don't want to change your current API design, here's a suggestion to improve your approach:

1. channel security: use TLS to protect data in transit (although I take it for granted that you use TLS already, I mention it for completeness)

2. data security:

   1. you can hash the postcode or the last name at the client side, and use the hashed value as the query parameter. This requires you to also store the hashed values of the postcode and last name to your DB in order to validate, OR
   2. you can encrypt the postcode or the last name at the client side, use the encrypted value as the query parameter, decrypt the parameter at your endpoint and use the decrypted value to validate (this saves you from storing the hashed values in your DB - but requires a key management solution)

---

¹ e.g. TLS
² e.g. encryption or hashing
³ as an example, see here or here