That's not what "security by obscurity" means. (I had the same question a while ago about something similar, so I learned the distinction.) If my secret is kep

That's not what "security by obscurity" means. (I had the same question a while ago about something similar, so I learned the distinction.) If my secret is kept at "example.com/sadf23s[...long uuid...]" then that is not an example of security by obscurity, any more than a username/password combination is. Indeed, my long url is almost certainly much longer than the majority of user's username/password combinations. It is potentially sharable, if that's something I'm concerned about, but that can be managed via cookies, timeouts, single-use urls, etc. And I also might be ok with it being sharable, just not discoverable. (e.g. Google Sheet's distinction between "anyone with a link can access" sharing and "anyone on the internet can find and access.") "Security by obscurity" refers to relying on some part of your architecture or code being obscure. E.g. hoping that no one knows what static salt you use in your simplistic hashing function, or hoping that no one learns that there is a page called "s3cr3t-admin-access.html" that lets you get into your site without a password. The usual test is: if an attacker had access to all my source code, could they get in? In the case of randomly-generated uuids as urls, the answer is "no." "System security should not depend on the secrecy of the implementation or its components."