0

I'd like to create an API to get customer details.

The url can be as Get https://../customers/{customerId}.

My question is customerId is sensitive, Is it Ok to pass it in url?

If not, what would be the best way to do that?

abcdefq355
  • 3
  • 3
  • The obvious answer here is NO, but what makes the customerId sensitive?? – Erik Aug 19 '21 at 04:49
  • You can encrypt the value, and or hash it with a time value, but I don't see why you would bother going to all that trouble for an ID. This means that other elements of your API are insecure if you are worried that a user might pass through the wrong ID – Chris Schaller Aug 19 '21 at 04:51

2 Answers2

1

It's odd that customerId is a sensitive part of information. Also you don't share much context. The options I could think of to make it secure I would:

  • replace the sensitive customerId to a be linked to a UUID or other non-sensitive information then look-up from the UUID to find the real customer.
  • use POST and https so whatever sensitive information is secured
Sirode
  • 379
  • 1
  • 2
  • 13
  • Yes, the first suggestion: it will require front end to have a mapping mechanism, which could be a bit overkill. And is POST and https secure enough? – abcdefq355 Oct 26 '21 at 23:30
  • Is https with GET secure? – abcdefq355 Oct 31 '21 at 23:25
  • If you have a correct setup (i.e. valid certificate for HTTPS) then the payload of your POST over HTTPS is secured (banks and payment forms are doing this way). GET on HTTPS is secure for the HTTP Headers, but not on the URL parameters of the GET that are senf plain text. – Sirode Nov 01 '21 at 12:16
0

The first question, is customerId really sensitive? At some point your client will pass the identifier for resources through to the API. Even if you encrypt the value, or package it within the payload as a POST request, the value can still be inspected and can still be faked by a client or packet sniffer who really wants to access or change it.

A: Yes, you can pass the customerId in the url

This is a standard expectation in fact it can be counter intuitive to try to work around passing the Id in the route, it will be far easier to code for and manage a REST based API if the Id is part of the route.

But it is possible...

The specific implementation will depend on your runtime and code framework, but as a design pattern It is possible to write a re-write module or middle-ware into the server such that an encrypted query string is decrypted and then the response pipeline redirected internally to the internal or secure route. By doing it this way, you are injecting this security layer in between the standard API processing and do not have to code in any special hacks at each endpoint to resolve the Id that was passed from the client.

However...

This means that the client side will have to encrypt or compute the value to send to the API, which means that now the client has the code that can create the tokens so it is a trivial task to reverse engineer the logic and create your own tokens to other customers.

Instead of encryption

In the last project I came across like this, it was a vanity issue. We didn't want the user to try and hack the system by changing the Ids in the URL and in some cases they just didn't want the user to feel like a number...

So in this case, its less about real security or confidentiality and 100% what I call Vanity.

In this way, the client calls an endpoint on the API with the parameters and it returns a token. I did use encryption in the end to avoid storing the original parameters, but the point is the API returns a token that it knows how to decypher.

You might be familiar with Tiny URL services, this is pretty much the same concept.

I found it simpler to user encryption, in this case the server holds both the encrypt and decrypt keys so I am not concerned that someone with an infected client could compromise security, but again, this wasn't implemented as a security feature.

Chris Schaller
  • 13,704
  • 3
  • 43
  • 81
  • Thanks for reply. Customer id is an example. If I put data in the payload or header, Is the payload easy to be inspected? Another question is if it's also insecure to store it in payload. Is it better to put it to oauth token? – abcdefq355 Oct 26 '21 at 23:23
  • That's a long time between drinks! The effort to read from the headers and the Content (payload) is pretty much the same, except that the headers will not be compressed, even if the content is. From a vulnerability point of view _headers_ are slightly more vulnerable due to the fact that at many junctions the headers are more likely to be logged than the content, but from a security in-transit point of view there is not much difference. Good discussions here focusing on the SSL encryption: https://stackoverflow.com/q/187655/1690217 – Chris Schaller Oct 26 '21 at 23:36
  • Thanks, If the https is enabled, both header and content will be encrypted during transmission, am I correct? Does that mean everything(content & header) is secure if I enable https? – abcdefq355 Oct 27 '21 at 22:49
  • Https (TLS) is the standard security level, but it only protects the message in transit. There are other reasons where you might chose to use other forms of encryption or hashing, but it is not common to consider the customer id as _sensitive_ so there is less guidance in the docs. I have one API configured to extract URL tokens from the claims provided within the authentication token, which means the CustomerId is never recorded or available in plain text, but the backend code "thinks" that it is, so we don't have to do anything special on the server end, but the client end needs changes – Chris Schaller Oct 28 '21 at 01:35
  • But yes, headers and content are _secure_ when using https, only the url is easily accessible. But I'm still confused by why it matters. I think it is important to resolve this as it's a significant change from normal implementations. It's sounds to me like this is an XY problem: https://xyproblem.info/ – Chris Schaller Oct 28 '21 at 01:46
  • E.g. If it's a banking system. customer id is considered as sensitive. The API was designed to pass the customer id in an OAuth Token. Do you think it's a solution to hide the customer id? – abcdefq355 Oct 29 '21 at 02:14
  • If the customerId is in the OAuth Token, then it is possible to inject the Id into the route on the server side, so I would still develop the API as if `CustomerId` is part of the route, but use middleware to inject it. Your question was "Is it OK to pass it in the URL" and I still say yes, but if you don't want to then there are ways around it. As to what is _Best_ that will attract opinionated responses. Check out my profile If you are interested in a 1:1 consult. – Chris Schaller Oct 29 '21 at 03:11
  • Yes, it's a good idea to inject it into middleware when using OAuth Token. And do you think it's a more secure solution to put it in OAuth Token and inject it in middleware on server side or it's the same as passing it directly in the URL? – abcdefq355 Oct 30 '21 at 00:29