| > With proper data permission check, having predictable ID is totally fine. That qualification is doing a lot of work in this sentence. For supporting evidence as to why this is the case, a quick search for "CVE PHP security vulnerabilities" or "CVE NodeJS security vulnerabilities" will produce voluminous results. > And UUIDv7's random part is large enough so that it's much harder to predict than auto increment id. Usually. One common scenario where using UUIDv7 for primary keys in a persistent store can be exploited similar to sequential integer ID's is when there are queries supporting pagenation and/or those leveraging the temporal ordering UUIDv7 supports intrinsically. For example: id > aSynthesizedUUIDv7Value
Note that this does not require successful identification of either the `rand_a` or `rand_b` UUIDv7 fields[0].> If your security relies on attacker don't know your ID (you don't do proper data permission check), your security is flawed. Again, I agree with this in theory. But as the saying[1] goes: In Theory There Is No Difference Between Theory and
Practice, While In Practice There Is
0 - https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-versio...1 - https://quoteinvestigator.com/2018/04/14/theory/ |