I have a simple content database. Should I use "id" so that people don't view it in the url?
The first and most important step is to use some form of role-based security to ensure that no one can see data they shouldn't. So, for example, if a user should only see their own information, then you should check that the ID belongs to the logged in user before displaying it.
As a second layer of protection, it's a good idea to have a unique key that prevents you from predicting other keys (a hash, as you assume, or a UUID). However, this still means that, for example, a malicious user who obtained another user's URL (for example, sniffing the web, reading a log file, viewing someone's browser history) could see that user's information. You need authentication and authorization, not just ID obfuscation.
source to share
It depends on your situation, but for my part, I think if you think you need a hash, you need to hash. If someone could pass data by my, say, iteration through:
... url.com?id=2134 url.com?id=2135 url.com?id=2136 ...
Then, using a hash for the id should be avoided as it will be much more difficult to determine the next one. However, keep in mind that you don't want the hash to be too obvious, so a determined attacker could easily figure it out, for example. just by taking MD5 2134
or whatever number you had.
source to share
Well, the problem here is that the real Hash is technically one way. Therefore, if you have hashed data, you will not be able to recover it on the receiving end. Without knowing what technology you are using to create your web page, it is difficult to make any specific suggestions, but if you must have sensitive information in the query string, I would recommend that you at least use a symmetric encryption algorithm so that people are not just reading meanings and reverse engineering things.
Of course, if you have the option, it may be best not to have this information in the query string at all.
source to share