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.

  • Are you using TLS?
    – schroeder
    Aug 15, 2023 at 11:28
  • 2
    Assuming you're using TLS, PII as GET parameters tend to be logged which is one of the reasons it may be preferable to avoid them (depending on logging policy and security). Aug 15, 2023 at 11:34
  • 2
    TLS isn't really a relevant protection for this issue as even with TLS it leaks through browser history, browser plugins, proxy servers and http referrer headers
    – wireghoul
    Aug 16, 2023 at 5:50
  • in addition to the other concerns, you should never do any "state-changing" actions (such as validating a user) upon a GET. A search is not "state-changing" so can be done via GET without the same risks. (A malicious crafted URL/link that a victim clicks on...) Aug 18, 2023 at 21:27

3 Answers 3


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).

  • In the UK there are 1.1 million post codes, that means each represents about 63 people, maybe 40 adults. So that is quite a lot of information.
    – gnasher729
    Jan 18 at 20:12
  • 63 people can be uniquely identified typically by just 1 more piece of information (or 1 more degree or vertice). That makes it 2 pieces of information to uniquely identify …. Which is not even a lot. It’s 2 bits of information. (And if think that’s not true, consider this… base 64 encoding uses 64 characters to encode everything. Meaning we can uniquely assign each person 1 to uniquely identify them per post code.
    – LvB
    Jan 19 at 2:19

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...)


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 level1 nor at the data level2).

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 legislation3 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)

1 e.g. TLS
2 e.g. encryption or hashing
3 as an example, see here or here

You must log in to answer this question.

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