It makes no sense to encrypt this since the unencrypted information will be available in the client.
Facebook does not encrypt anything even because the engineers who work there know that it has zero effectiveness to do this.
If you don’t want to use the table ID use another unique key, but in essence gives in the same.
No use hiding the sun with the sieve. If you want security validate everything that arrives from outside and do not let user do what can not. If there is a risk of someone taking the ID and doing what should not be an application problem, fix this problem.
If any user has to have some right to do something potentially problematic, authenticate it to know who it is, give the privilege only to those who should and create a log to audit if someone does what they should not. Those who have no privilege cannot do something wrong.
If everything is secure, the exposed ID is no problem, no matter if it is a primary key or not.
The only problem that can happen is you one day decide to change all Ids sequencing, something that shouldn’t be done, but if you do and someone has an ID in the old model, there may be some inconsistency, but again, it’s an application problem.
There is no way you can associate an exposed item without a single piece of information that links to the database. And I’m talking about something mathematical/physical, it’s not just that you don’t have a technology that accepts that.
In the applications that I worked with, the id is only and exclusively for relationship control but as control of internal information, for example to make an update in the bank. Never hear the need to "show" a PK. What would be your need?
– gabrielfalieri
When I need to use the data in the view in this way, I usually associate it with an html element. For example, in tr I assign an ID in the rendering, this id I can use in JS. If you need to create an additional attribute, it is also possible, such as data-pk=$id.
– David Dias
Whether it’s safe or not, I honestly don’t see the need to have this fear. These negotiations are solved with session token, authentication middleware, etc.
– David Dias
I updated the publication by citing an example.
– Rodrigo Roberto de Almeida
I understand, but using JS data-tags would still not be making ID/PK available for source code? I mean... Assuming the ID in the database is 123, the html would not be:. <div id="cmt" class="comment" date-id="123"> Text </div> Continuing to be "explicit" ?
– Rodrigo Roberto de Almeida
Yes, it will. Explain. I don’t have as much information to make you safe that this is not a bad practice, however, I see in several systems this and use so, I believe that there is no problem to do this, as long as you are sure about the negotiations in the backend. Quick thinking, an alternative, would be a reference in HTML that, through an API (token, magic logic, I don’t know) return the PK for you to use.
– David Dias
But, I honestly don’t understand why you want FK in the view. An example about my uses: In Model I deal with Fks. In this way, consider that everything is solved through the methods already defined that abstract the calls, like: User, Comments. Users have comments. Comments belong to User. That way, you don’t need to pass the FK, just the comment ID, for example. By accessing the user’s comments, you will have the specific comment by the ID. .
– David Dias