Lets say we have a hypothetical system where there are various files are added by users and are sensitive, e.g. lets say an attachment to a private message. It's not that easy to verify access rights usually (in terms of implementation), since attachment can be added to multiple objects, etc. So a common way to implement it is something like that:


Lets say that the id that is used is generated using secure PRNG (not a guid or something) and it's virtually not possible to guess. Will that provide adequate security or the risk of the URL exposing is rather high?

Possible problems include users exposing these urls, so it does not seem very secure even with non-guessable urls to me if the attachment can contain any sensitive data, but it's interesting to know the thoughts of security experts on that.

P.S. I have found this URL on github where this exposure was a real case. A developer thought that URL is protected and published on a public place but it appeared to be not the case.

marked as duplicate by Xander, Ohnana, Steve DL, Neil Smithline, Deer Hunter Jan 29 '16 at 7:36

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    This is a security risk if users shares a link to a low security document containing links to a differently privileged document. The user may not check every links in a 100 page documents. You also lose control over visibility of privileges, in an audit you won't be able to answer questions such as "who had access to this resource". – Lie Ryan Jan 29 '16 at 0:34
  • I am not sure why everyone is marking this as duplicate, because it's not the same as asking about GUID security, in my question the prerequisite is that we have a secure token and the level of security with this assumption – Ilya Chernomordik Jan 29 '16 at 8:03
  • @IlyaChernomordik what matters is not how good your tokens are, but the fact that URLs have some expectations of publicness and stick around for a long time. The NSA, Google and maybe some ISPs would also be downloading your attachments. Anyone eavesdropping on a public WiFi network could download them too. Access control is authentication + authorisation, not pseudo-secrecy. – Steve DL Jan 29 '16 at 12:00
  • I will have only https and without https any means of protection are pretty ueless I guess, so there is no worries about eavesdropping there, but I see the other problems mentioned as serious ones. I really did not doubt it much, but wanted to get a proof to my thoughts that it's not secure enough. – Ilya Chernomordik Jan 29 '16 at 12:20

While it definitely does provide a degree of security, it still leaves you a number of security holes that may or may not matter dependent on the type of application you are developing. For a non-exhaustive list:

  • Content may meant to be limited to a select group of users, what if one of them leaks the URL?

  • URLs with GET parameters are stored in a large number of places - web history for example

  • Occasionally you see major issues when google crawls things they are not meant to, for example the instawallet fiasco.
  • Security vulnerabilities elsewhere in your site may expose the links, and with no additional security they will be exposed.

If I were you, I would want to implement additional security by tying files to specific people/groups who may be able to access it, and confirm their session prior to serving the content.


Use of long random tokens as secrets to provide access to a file can provide effective security. I'd recommend 128+ bits to make it truly outside the range of randomly guessing. You could probably get away with fewer bits, especially if you rate limit IPs based on bad guesses. E.g., if you had a 64-bit or 80 bit token and a billion such files and were attacked by a botnet with a million distinct IP addresses that each could each try 10 guesses every 10 minutes -- say you banned an IP for 10 minutes after 10 incorrect attempts, it would take them about 12 days (64 bit token) or 2300 years (80-bit token) to find a single random file.

However, to do this in a secure manner you should keep some caveats in mind:

  1. Use HTTPS. Network eavesdroppers can see (or secretly alter) any traffic over HTTP.
  2. If the document has links to other webpages and a user clicks said links, the web-server at the other end will generally see a HTTP Referer header in the HTTP request which will provide the full URL (including any secrets; this is even if the secret is in a query parameter like https://www.google.com?q=secret ) and will still happen if the user is in private browsing mode.
  3. The random token probably may be stored in your computer browser's history (unless you browse in private mode and end your session).
  4. Some search engine gets hold of your random token and indexes it.
  5. The mechanism for informing the user of the key possibly leaks it to third parties. Email is potentially exchanged unencrypted and if you use an third-party email provider your secret key is accessible to administrators at that email provider. Many users also save plaintext email to their computer with an unencrypted disk (e.g., the hard drive may be removed or someone boots into a live cd to read the disk's contents) or leave the computer logged into their email account.

Issue 4 can be usually avoided by maintaining a robots.txt and forbidding a directory.

User-Agent: *
Disallow: /private/

You can mitigate issues 2 and 3 by requiring the user to request their document by HTTP POST (over HTTPS). That is instead of clicking a link like:

<a href="https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw">File</a>

You could do something like embed the following in a HTML email:

<p> Click the button below to get your file:
<form action="https://example.com/private_file/" method="post">
  <input type="hidden" name="token" value="LfliQdgOAkjs9H0Oi5ZZcw">
  <input type="submit" value="Get File">
<p>Or go to https://example.com/private_file/ and cut and paste the token <pre>LfliQdgOAkjs9H0Oi5ZZcw</pre>.

This would prevent the secret from appearing in your browser history or receiving referer links (as the URL would simply be https://example.com/private_file/).

Alternatively, you could allow links of the form https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw, but then redirect the user to another URL when actually serving the private https://example.com/private/document. This would prevent issue #2 with Referer headers, but still may leave the link in your browser history.

  • So after all I suppose it's better to provide the access control instead of relying on all the workaround. Seems it's similar to fixing SQL injection by escaping instead of parameterizing queries :) – Ilya Chernomordik Jan 29 '16 at 8:26

These types of questions come up from time to time.

Essentially, this is security by obscurity.

The fact that it is hard to guess only addresses one type of issue. It does not protect against:

  • Users accidentally sharing the link, bookmarking the link, etc.
  • The user accidentally typing the url into Google or another search engine, resulting in it being indexed.
  • External monitoring or network traffic interception, caching

You may be interested in this example with DropBox and similar from a few years ago:

The vulnerability was discovered by cloud-based file locker Intralinks in a Google AdWords campaign in which its services are advertised using keywords that identify its competitors, which in this case are Box and Dropbox. The vulnerability exists when users share files via share links, which are then subsequently inserted into the search box (as opposed to the URL bar) in their browsers; this allowed Intralinks to collect the data in the AdWords campaign management interface.

In the same fashion, users are vulnerable to a slightly different attack that involves the relay of HTTP Referrer headers, as Dropbox outlines in this example scenario:

A Dropbox user shares a link to a document that contains a hyperlink to a third-party website. The user, or an authorized recipient of the link, clicks on a hyperlink in the document. At that point, the referrer [sic] header discloses the original shared link to the third-party website. Someone with access to that header, such as the webmaster of the third-party website, could then access the link to the shared document. In the same post, Dropbox notes that the problem with the search box is "well known and we don't consider it a vulnerability." Ultimately, the only protection that the shared files have is that they are difficult to get to, requiring an exceptionally long URL to access — in effect, security through obscurity.

Putting a picture in front of a safe is not the same thing as locking the safe...

It sounds like you are trying to avoid implementing real authentication. You may want to look into implementing real access control (authentication and authorization) as well as something like information rights management.

At the very least you could ask for some code, token, or identifer when the file loads as a gateway before providing access. E.g., you send the link by email and they can only get to the actual file once they enter their email again. Provides some protection against accidental indexing, but not other cases.

  • 2
    Use of random tokens is not security by obscurity. Security by obscurity is when security is lost if the implementation details (e.g., source code, algorithm) become available to the attacker. This contrasts with security by design where the implementation can be publicly known and only secret keys (passwords, random tokens, private keys) have to be kept secret. In this case the secret key is the randomly generated token. Of course, this fails if the secrets are leaked. – dr jimbob Jan 28 '16 at 17:06
  • 1
    It is security through obscurity, because you rely on the secrecy of the URL to provide access control, ignoring the status and life cycle of URLs. See my answer on the duplicate question. – Steve DL Jan 28 '16 at 23:35
  • @SteveDL Your duplicate question asked a different question. That question was about having all content served from one obscurely named directory that then hosts all the content. The reason that doesn't work is the same reason all paying subscribers to the Wall St Journal shouldn't just be given the same password for simplicity. The password would leak. See the answers to this very similar question ( security.stackexchange.com/questions/36870/… ), where the answers agree it is not security by obscurity. – dr jimbob Jan 29 '16 at 1:53
  • What you're discussing is a matter of scope. People use passwords as secrets with the expectation that they are treated as secrets. Passwords (assuming used over encrypted channels) are not cached by search engines or browsers, they're not collected by your ISP and some government agencies when you browse the Web, and so on. URLs are not treated as secrets, which is why using them as such is security by obscurity. You're just hoping there'll be enough other URLs of interest that yours will go unnoticed when your users access it. – Steve DL Jan 29 '16 at 11:54
  • 1
    For instance it's not a problem to use secret URLs for password reset links, because those links expire after one use. It is a problem to use secret URLs to access stored documents. – Steve DL Jan 29 '16 at 11:55

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