On sites like Facebook etc. you have the ability to create "private" photo albums that are only shared with selected friends, similarly in Messenger you can upload an image just to a specific chat.

In the context of privacy and security on a social network, I'm assuming most people think these images etc. are secured. But are they?

Am I right in assuming that actually the security comes from the fact that an uploaded image just has some kind of extremely hard to guess guid that forms the url? The fact that an album is hidden, therefore projects the urls for it's contained images being seen, but if someone had the URL for a specific image they could view it regardless.

I know you can use scripts that generate an image (e.g a php script) whereby the image itself doesn't have an actual URL and is above the document root, but is more of $_GET parameter and the script could therefore enforce security. But something the scale of Facebook and Google where you would be relying on CDNs to deliver this content, a script handler for every image doesn't seem viable.

Am I right in assuming it's actually just security through obfuscation? Or do these sites employ some kind of sophisticated ACL to actually control access to individual images? How should this be handled in the context of social networks e.g more image based then truly sensitive files? (though obviously an image itself could be sensitive to the uploader)

2 Answers 2


This question dives deep into the AAA stack of identity and access management so we can start there.

  • Authentication
  • Authorization
  • Accounting

In a well defined AAA system you have to determine a method to evaluate the status and sensitive of many objects and entities. Users, computers, pictures, and other forms of data within a AAA system need to be properly protected through these methods. There are many ways to do this including the use of databases, file meta data, ACLs and more.

To make this example float, I'll use google drive as my main focus. On google drive, every document you create is given a specific URL which can be shared around the globe. However, as the file creator you get to determine who has what type of access. For example, you can state that the user must be logged into google through a specific account. You can further state that some individuals who are logged in only have read permissions while others have write permission. How this is stored is not the biggest concern, but I imagine they use some form of a database engine to track this ACL.

Continuing this example, I've now created a file with a specific AAA policy. I have created a policy that requires people to log into google (Authentication), and I've created a specific set of people that are allowed to view or edit the file (Authorization). Google, will then enforce this policy such that even a user with the correct URL cannot have access without first Authenticating and being authorized. Assuming there are no breaches of security, this file is now secure to the people I have authorized.

This is where security becomes a major factor. If google doesn't apply the AAA framework appropriately, my files can be exposed. In fact, Google actually had a recent data leak because they failed to enforce AAA properly. It's not that they couldn't have secured the data, it's that something was missed and users were able to see data they should not have because the Authorization mechanism was not responding properly.

So, in summation, AAA security is a lot more complex than having a GUID or URL when applied properly. Through various means, files and users are given attributes which can be used to evaluate who has access, what access they should have, and even why. It is then up to individuals, companies, and governments to hold the AAA system owners accountable for security and remediation of failures to prevent the implementation of poorly designed systems.

  • Thanks for a very comprehensive answer, are you able to elaborate a bit on how this might work? For instance with the metadata, and how the authentication checks work from a practical/implementable sense. I know we shouldn’t reinvent the wheel with these things so I will look at existing solutions, but I’d be keen to get a grasp of it. A link as a comment will suffice thanks
    – TommyBs
    Commented Jan 8, 2019 at 19:22
  • This might be a good way to look at if, from a code perspective: book.cakephp.org/2.0/en/tutorials-and-examples/… Commented Jan 8, 2019 at 19:24
  • I get the code perspective there securing an actual url like post.php as you’re explicitly running the post.php script. It was more specifically about securing something like an image that isn’t generated on the fly but has its own url and in the context of a cdn etc. Is that more likely above the application level?
    – TommyBs
    Commented Jan 8, 2019 at 19:30
  • AH, I understand better now. From a web application perspective, the web daemon is able to access more of the server than is addressable through a URL space. As an example, PHP running on APACHE can reach /tmp on a Linux host even through it is not directly navigable through a URL. Using these types of folders (you can configured more), you can store sensitive information in a place that is safe from direct browsing and still present when the right user has been authenticated. Commented Jan 8, 2019 at 19:41
  • Again I get how to do that as well, but I also know having a script to do this is more memory/CPU intensive, in big sites like Facebook where they try to squeeze every bit of performance and use global CDNs etc that are just for serving these images I assume that’s not a viable solution either
    – TommyBs
    Commented Jan 8, 2019 at 19:45

I know you can use scripts that generate an image (e.g a php script) whereby the image itself doesn't have an actual URL and is above the document root, but is more of $_GET parameter and the script could therefore enforce security.

Using a random, long string, (such as GUID) is basically a form of authentication. You can't brute force it, there's a lot more possible values then there's pictures, and the can be of limited lifetime.

Cookies commonly do the same thing; hold a long, random string that the server can use to look up your privileges, and cannot be reasonably brute forced. The difference between it living in the URL (which is part of the headers sent by the browser to the server) or cookies (which is also part of the headers...) is not important to security.

Having authentication as part of URL may be problematic in some settings, because browsers typically doesn't treat this as private information, so it is shown plainly on screen, and saved in a easily accessible history file, with no mechanism for the site to mark it as privacy-related. This may be problematic on shared computers.

Overall it's a practical solution that is fairly secure against accidential discovery.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .