For a Multi-Tenant database, is it safe to pass Tenant ID’s as GET parameters to the API?

Given a Multi-Tenant database, if I were to create a website with any of the popular JS-based UI platforms (ie: Angular, Vue, etc), and assuming both the site and the API are using HTTPS, is it safe to pass Tenant ID’s as QS parameters to the API?

To explain more, let’s say we have a table in the DB called Customer and it has a primary key column called CustomerId which is an auto-incrementing integer. There will be some API endpoints (well, most, actually) that need the CustomerId as a parameter.

What I’m not sure about (still new to JS-based UI platforms) is if I need to be concerned about this CustomerId being easily spoofed. For example:

“If MY customer ID is 32891, then let’s see what happens if I make the same API call using 32892 instead!”

If both the site and the API are HTTPS, is this a concern? Or, should I also give every customer a GUID and use that in the API parameters instead?

(To be clear, I’m not asking about query strings parameters that are clearly visible in the browser address bar. I’m asking about GET calls to the API where these ID’s are passed as a query strings parameter. Also… the API itself is secured using JWT to prevent unauthorized calls. And not that it matters but the API is built using C# in .NET 5.0)

Answer

I would suggest the customerId to be part of the JWT payload (search for jwt claims and how to add custom ones when generating a token).
This way you will be sure that it it is not modified by malicious user.

You can still pass it as query parameter if you want, but you have the option to do a validation, by comparing the query value with the value in the JWT.

Don’t trust the users. If they can change they customerId and manipulate the request, that is a security issue.

Another option is to not pass the customerId at all, but instead after authorizing the user to do a database call and see what is his customerId. I personally would prefer the first option, because you won’t have to do additional database call.