I guess, a good fence on your property does not prevent you from having a hardened door for your house in order to mitigate possible failure in the fence, and I believe this is what is being explained here.
You should not only rely on one utility like Laravel policies because it might fail because of a human mistake or a script failure (security breach). UUIDs are an easy way of mitigating any leak in your policies until you find the root of the problem (or a patch is being published for the package used for managing policies by the maintainer of Laravel Policies).
Security has always a cost. It should not be compromised for the sake of performance or memory usage (even if this is interesting to know that this has a greater impact than using integers as primary keys).
Also, the article you linked talked about UUID as primary keys, whereas Khalyomede's solution is all about an additional column. And if you look a little closer, your article is describing in the end the exact solution used by this package (Mapping UUIDs to Integers).
Best solution from a security perspective is and will always be to have a working authentication layer. Obsfuscating (by using UUIDs instead of IDs) will never be a replacement to that. Attackers can adquire the identifier in any other API endpoint that you have exposed.
If you have a working authentication layer, you definitively should not pay the performance costs of using UUIDs for the sake of obsfuscation.
If you're worried that in the future, your authentication layer may break because of human mistakes, you should create integration tests to ensure that the issue is detected before it reaches production.
Putting security aside, sometimes you do have to use UUIDs for different reasons, like uniqueness across different systems. Here is where tactics like mapping UUIDs to integer help.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I guess, a good fence on your property does not prevent you from having a hardened door for your house in order to mitigate possible failure in the fence, and I believe this is what is being explained here.
You should not only rely on one utility like Laravel policies because it might fail because of a human mistake or a script failure (security breach). UUIDs are an easy way of mitigating any leak in your policies until you find the root of the problem (or a patch is being published for the package used for managing policies by the maintainer of Laravel Policies).
Security has always a cost. It should not be compromised for the sake of performance or memory usage (even if this is interesting to know that this has a greater impact than using integers as primary keys).
Also, the article you linked talked about UUID as primary keys, whereas Khalyomede's solution is all about an additional column. And if you look a little closer, your article is describing in the end the exact solution used by this package (Mapping UUIDs to Integers).
Best solution from a security perspective is and will always be to have a working authentication layer. Obsfuscating (by using UUIDs instead of IDs) will never be a replacement to that. Attackers can adquire the identifier in any other API endpoint that you have exposed.
If you have a working authentication layer, you definitively should not pay the performance costs of using UUIDs for the sake of obsfuscation.
If you're worried that in the future, your authentication layer may break because of human mistakes, you should create integration tests to ensure that the issue is detected before it reaches production.
Putting security aside, sometimes you do have to use UUIDs for different reasons, like uniqueness across different systems. Here is where tactics like mapping UUIDs to integer help.