23

I need to generate UUID to eventually store in a database. Can I generate theses UUID from Javascript on the client browser (There are some examples here)?

Is there any security risk of doing it this way? I understand that anyone can modify the UUID before it's passed to the server for storing. So i'll need to check if they are trully unique before storing them in the database, but other than that, is there any other things to checkout?

(Sorry for my english, feel free to correct any grammar errors)

edit: To answer questions about why I would want to do this, it's because I can create a new object and it's identifier in Javascript and add it to my view and then make an AJAX call to the server to add it to the database. This way, I don't need to load it back from the database to know what is it's primary identifier.

Community
  • 1
  • 1
Mathieu Pagé
  • 10,764
  • 13
  • 48
  • 71
  • I think it could be a security issue with letting the users see your UUID generator code. In theory, it could then be possible to generate existing UUID's of for instance other users session ids and such. – Andreas Zita Jun 10 '14 at 09:16

4 Answers4

26

Not really. As long as it's a simple identifier and nothing more, and you are indeed checking it for validity and uniqueness, it's no different than user accounts having an id in the url, for example.

Look at your URL bar. I bet 1296234 is the primary key of this question, but I can't really do anything with that information. Same deal with your script.

ryeguy
  • 65,519
  • 58
  • 198
  • 260
  • Thanks. I did not tought anything wrong could happen, but I wanted to be sure I was not overlooking some kind of well know attacks. – Mathieu Pagé Aug 18 '09 at 23:17
2

What benefit do you see in generating these client-side? In all honesty, the best option is to generate it server-side, out of the users reach. It may not give save you from any serious security issues, but it will cut down on redundant validation.

Sampson
  • 265,109
  • 74
  • 539
  • 565
  • 2
    I know this thread is old but generating the ID on the client is needed if you are using fully idempotent create REST calls. Another alternative would be to query the server for a new ID and then use that ID in the create REST call. That however means two calls to the server. – Bernard Feb 17 '15 at 23:21
  • 4
    @Sampson I never thought I'd have to generate a UUID on client side but now, I'm interested in offline web application and having UUID generated on client side is perfect for this use case ! – maxime1992 Jun 18 '16 at 19:28
  • If you're following strict CQS and you need the ID right back (e.g. to redirect to a proper view), it's a good way of doing so. – Shocked Apr 17 '17 at 08:59
  • to allow for delayed server-client data syncing, generating an id on the client is pretty much necessary. – bryanph Jun 06 '17 at 16:33
  • @Shocked why do you think it matters where you create the Id in case of CQS? – GoldenAge Jun 27 '19 at 13:14
  • And I need to add that if the implementation of the CQS is not strict then the system is probably not scalable. – GoldenAge Jun 27 '19 at 14:28
  • @GoldenAge if you want your commands to return nothing (as they should), there is no good way of getting your ID back. – Shocked Jul 16 '20 at 11:54
  • 2
    @Shocked in such case you can just create an Id at the same level where you create a command object. So this way you can perform an action such as e.g. `1. var fooId = Guid.NewGuid(); 2. SendCommand(new DoSomethingCommand(){ FooId = fooId, ...}) ;3. var data = SendQuery(new GetFooQuery){FooId = fooId};` – GoldenAge Jul 17 '20 at 11:25
  • @GoldenAge right, but then you need to break CQS on the line client-server. JS will post a command but will get a query result in addition – Shocked Dec 08 '20 at 09:25
  • It's convenient if you do optimstic updates on your server state cache (in the client) without refetching after the mutation. That way your server state is always up-to-date with the real ids. – Emmanuel Meric de Bellefon Jul 13 '23 at 17:58
2

Is there some reason you can't have the database generate (increment) an ID?

If, like you say, you'll have to check the uniqueness of the value before submitting it anyway, why not just have whatever backend language you are using generate it. That would make it much more opaque.

Josh Lindsey
  • 8,455
  • 3
  • 24
  • 25
1

Yes. The risk is not specific to UUID, any client-side generated ID has some risks, depending on what you do with the ID. The problem is that it's very hard to authenticate the Javascript. If you accept ID generated by client, you accept any IDs from the hackers.

The risks may include,

  1. Session stealing. If you use the ID to identify the session, someone may use an existing ID as generated ID and the server may treat it as an existing session if proper care is not taking.

  2. Duplicate keys. True UUID is random but someone can generate duplicate keys which will mess up your database.

You might find ways to defend against each of these attacks but that's passive protection. It might defeat the original purpose of generating IDs on the client, which is simple.

ZZ Coder
  • 74,484
  • 29
  • 137
  • 169
  • 9
    If you identify the session id then you are hacked on any website.. point 1 is not a valid point. – Totty.js Jul 11 '17 at 18:02
  • 12
    Your second point also shouldn't be an issue, your database should have a uniqueness constraint that there cannot be duplicate UUIDs, and if someone tries to submit data reusing the same UUID then the update should be rejected. – Bob Whitelock Aug 13 '18 at 09:58