Some sites utilize a GUID for a file name when it goes in storage. For example, when you load up a receipt, instead of having the receipt named something like 1200 (an incremental number), it will have a GUID instead. What is the purpose of using this GUID if the underlying back-end code permissions checks are in place (User must be admin with receipt reading permissions or must be the receipt owner) instead of leaving in the incremental numbers in place?


Because generating a new GUID is trivially easy, whereas keeping track of which was the last sequence number issued and making sure that the next one is issued only once (no multi-user timing problems) is much more difficult.

Also, a GUID leaks no data; a sequence number discloses the number of files being stored.

  • I don't think the first part of this is correct. GUID generation is non-trivial because it is generally pulled from a CSPRNG in most implementations. An incrementing ID is trivial because there will be a database record expressing permissions around the file anyway, and the database can handle that auotmatically with an autoincrement PK. – Polynomial Mar 13 at 17:02
  • In dev terms, using .NET Guid.NewGuid() returns a new GUID from the framework. Yes, it will use resources to generate it, but it's still much faster and resource-lighter than database accesses and requires far less code. – simon at rcl Mar 13 at 17:15
  • I disagree. The Guid.NewGuid() call, on Windows at least (.NET Core on Linux uses a different mechanism) calls CoCreateGuid which performs a DCE RPC to UuidCreate, which invokes AES functions from the bcryptPrimitives library and ultimately invokes a CSPRNG, which means GUID generation is fairly slow. Since you have to store the GUID somewhere along with a security descriptor, there's an implication that a database exists as part of the application architecture. As such you're going to be inserting rows anyway; might as well just autoincrement an integer. – Polynomial Mar 13 at 17:22
  • 1
    In fact your assertion that it requires "far less code" is an odd one; an autoincrement requires no code at all as the column definition would be marked as autoincrement, so an INSERT statement would automatically generate the new primary key ID. If you're going to ditch the database and use filesystem permissions, why have a GUID anyway? Just use the filename directly, since it is guaranteed to be unique, or hash it if you need to obfuscate it for some reason. – Polynomial Mar 13 at 17:23
  • @Polynomial - these are all good points, which in general I totally agree with. However the question I was answering - why use a GUID for a file name? - contains no mention of a database and not much info about what the site does, beyond storing files. I took it at face value. – simon at rcl Mar 14 at 12:42

You're right that a GUID is unnecessary for security when proper access controls are in place. However, there are still reasons that a GUID can be useful:

  • A GUID makes it somewhat more difficult for a malicious user to identify other file records, in case there are vulnerabilities.
  • Given a pair of file identifiers, an incremental ID reveals which file was created/uploaded first, whereas a GUID doesn't.
  • The GUID option hides the total number of files on the system.
  • Some software designs use GUIDs for all objects as part of their design (e.g. applying security descriptors in a non-relational manner to avoid column duplication) such that no two objects have the same GUID regardless of whether the objects are of different types.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.