I have a few dynamically generated images on my server (of high business value), which are supposed to be viewed only via our mobile app. The image is simply loaded from the URL as PNG. How can I prevent people from accessing the same image just by using the URL (if they find it out)?

I could use a PHP script which requires a token to serve the image (rather than access it directly). But If someone goes and reverse engineers the mobile app, token can also be found. I could try and hide it really well, but isn't there any other, better solution?

  • Someone disassembling your app had to buy it and eventually REGISTER? – Adriano Repetti Nov 21 at 7:43
  • I'm not sure I follow. You can easily rev engineer apk file for Android for example. – Primož Kralj Nov 21 at 7:44
  • Yes, what I mean is that user, downloading the app, already has access to those images. You can use an unique app ID to create (server side) a JWT token. If, instead, to have the app is not enough to see those images and they have to subscribe...even better, same JWT token generated when registering – Adriano Repetti Nov 21 at 7:51
  • Thanks for mentioning JWT token. I don't know it, but I will research it now and see if suitable. One thing is that users don't need to register, so that might be a problem. – Primož Kralj Nov 21 at 7:52
  • 1
    @PrimožKralj I understand your concern, but if someone's determined to get the data, to the point that they'll reverse engineer the app, then no, there is nothing you can do. Including the fact that they're images, people can take screenshots from their phone and redistribute those. – ChatterOne Nov 21 at 10:06

You have to work with that images the same as it should be for restricted content. There are two major points:

  1. Protect access to the content (the images)
  2. Protect content against brute force not to allow user guess about image path.

The both points could be covered with proxy request through php script. The first point can be solved with authentication and protection content with a token and ACL (access control level). Make sure the images out of webserver visibility not to access image directly. It could be helpful to rename image after upload and save original name and new name in DB. In this case you can call it from app by original name and access it by new unique real name.

An answer for the question title: just require a login and password and check the user's authorization before sending the image.

An answer for the question body/comments: as mentioned by ChatterOne in the comments, as long as there is a free access to the app, there is no way to prevent the download by a determined person.

Basically, selling/providing the raw data is not the way to go. Selling a service is. As long as you are keeping your app as is, it will leak the data sooner or later. As long as you are constantly evolving, offering more analytics based on the data, more services, more customer satisfaction - data leeches will be always left behind.

Here are some ideas.

  1. Everything has to be SSL TLS v1.2+
  2. Having a login/password would be best
  3. Having succeed in logging the user gets a code random 64 bytes or more
  4. The request is modified so instead of https://www.etc.com/file you have https://www.etc.com/random 64 bytes or more/file
  5. The code expires either when the user logs out or time based
  6. Time base is more secure, and the app can fetch a new code every say 5 minutes
  7. Each code is internal tied to an IP address, and the user has to re-login if it changes.
  8. Any IP submitting false 64 bit token is banned. say 20 minutes.

If they MITM the SSL cert and packet dumped the traffic it might still be possible, but the bar is raised significantly. Certificate signing and pinning make this incredible difficult.

This way no fixed code is stored in the app. The user has to pass through a user/password check to even get said code. Even if you publish the source code a valid user name and password will still not be present.

Each user and if multiple logins per user are allowed each instance has a different key. If they have a cell phone and a tablet.

Without a username/password any process can be reverse engineered. The 64 bit token can't be easily guessed, but the process of getting one could eventually be guessed.

PHP has a "session id", and you could symlink the session id to the real folder internally. Deleting said folder after 5 minutes or etc. Probably better to use a secure random function.

  • PHP allows passing raw file contents to the output. Instead of moving the image to example.com/[random path]/image.png, you can just have example.com/image.png, and configure the web server to invoke /image.php which can check authentication, such as session IDs or other tokens in other cookies negotiated between the app and server... [continued] – Ghedipunk Nov 27 at 17:04
  • The image to serve would be kept outside of the document root in all cases... or even saved in a database in a blob field. The only thing you'd get if you're guessing paths is an endless stream of 404 responses. – Ghedipunk Nov 27 at 17:05

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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