Is it safe to use a UUID in a URL for semi-private data?

user_1532919 0
Viewed 1884

I run a landscaping company and have multiple crews. I want to provide each one with a custom URL (like mysite.com/xxxx-xxxx-xxxx) that shows their daily schedule. Going to the page will list the name, address and phone number of 5-10 customers for the day.

Is it safe/wise to use a UUID in a URL for semi-private data?

websecurity uuid security
2 Answers

Depends on how safe you want it to be.

Are the UUIDs used for anything else? If not, they are fine for creating random URLs.

But, browser history would allow anyone using the same machine to find the URLs. Also, unless using https, a network sniffer could easily see the requested URLs and go to the same page.

Another concern is spider bots. Make sure nothing links to those pages, use a robots.txt to prevent indexing the site, but you still might find that some of the pages show up on search engines. It might be better to have the UUID set in a cookie and check that for determining which employee it is, lest your semi-private pages start showing up on google.

user_39912110

Whether or not that schema would work for you, depends on your threat model (as well as some implementation details). Without a concrete threat model, it is not possible to give a definitive answer to your question.

I can, however, give you some ideas about potential issues with the solution, so you can determine if they are relevant for your application. This is not a complete list.

On the implementation side of things:

  • Not all UUID generators are created equal. Ideally, you want to use a generator based on a cryptographically secure RNG, providing an UUID where every byte is chosen at random.
  • Using the UUID for a database lookup or similar operation is not necessarily a constant-time operation (and thus there might be side-channel attacks unless you implement the lookup by yourself)
  • Make sure your URI does not leak via referrer
  • Some tools attempt to detect 'secret' URLs to protect them from history synchronization or other automatic features. Your schema will most likely not be detected as 'secret'. It might be better to artificially lengthen your URI and to move your UUID into a query parameter.
  • You can further reduce attack surface with the usual methods (rate limiting, server hardening, etc.)

On the conceptual side of things:

  • A single identifier for both identification and authentication is not necessarily a bad thing. However, in most cases there is a need for an identification-only identifier – you must not use the 'secret' UUID in those scenarios
  • If a 'crew' consists of multiple people: you cannot revoke access for a single crew member
  • Some software (antivirus, browser, etc.) treats information in URLs as public information, and might upload them without user interaction
user_26360010
Related