Preferences

AdieuToLogic parent
> 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/


This item has no comments currently.