The problem of leaving so is that, anyone can arrive and enter an ID at the end and access other information.
Let’s start over here.
First of all this is a safety factor, not a visibility factor. That is, to assume that the user X have access to the records of ID’s: 3, 2 and 5. Already the user Y have access to ID’s: 8 and 1.
If the user X type in the URL the ID 8 it is your security layer’s role to check if he has permissions to view the information from that ID.
Let’s simulate:
In a ballad, where there is VIP area and TRACK how are identified people who have access to VIP area? In case by bracelet. If there was no such "security" all the track could enter the VIP, correct?
This ideology must be imposed on your system. If the user enters a random ID in the URL your application should process its access in that record, do not try to hide the ID from it.
What I wanted was to know how to hide everything you have after the "?"
No need for that. Visibility doesn’t bring problems if you have a layer of security behind it. You’re flipping the balls.
Considerations
The important thing is not the visibility of the ID in the URL, but the ACL of its application.
SEO
Look for some articles also about SEO, that it is not recommended to work with numbers in the URL but SLUGS.
URL friendly. I’m running out of time to give you an example, but I’m sure someone will post an answer below.
– Diego Souza
Hiding this you know you’re going to have SEO problems, isn’t that a concern for you? If not, go through GET instead of POST.
– caiocafardo
If the problem is just
privacidade
information, then you could generate ahash MD5
and passes there as a parameter instead of passing only theid
naked and raw.– Ilario Junior
As they said, hiding will have SEO problems, IE, will not be indexed by the search engines, and does not solve the problem since the feature will be available in it. It is necessary to analyze who can see the data and under what conditions and with that in mind to implement these validations on the server.
– Filipe Moraes
Your application should predict wrong Ids, because by hiding them or not (whatever), every HTTP request can be forged in its entirety, regardless of whether it’s GET, POST or something else. Your concern is valid, but the path chosen to resolve it is illusory. If you really need security, exchange the ID for a key that is only valid for current session, and/or in the main application check if the logged in user has the right to access the provided ID.
– Bacco