1

I'm leveraging Firebase Authentication for downloading images from firebase storage. I'm also leveraging google API HTTP referrers for blockage by domain so that my image from firebase storage is only accessed from my website. But when I go to the network tab of my browser I can see the download URL of the image. By this, anyone can download my image and use it. What should I do so that my images are secured?

P.S: I'm using the firebase storage SDK and by following the documentation when I execute this code below

storageRef.child('images/stars.jpg').getDownloadURL().then(function(url) {
  // `url` is the download URL for 'images/stars.jpg'
  var img = document.getElementById('myimg');
  img.src = url;
}).catch(function(error) {
  // Handle any errors
});

I can see the download URL in the network tab of my browser.

CuriousHash
  • 385
  • 1
  • 4
  • 17

3 Answers3

2

You can't. When you give up access to a Cloud Storage download URL to any one, in any way, you are implicitly trusting that user to its access. They are free to share it with anyone they want. If you don't trust that user, then don't give them the URL.

If you don't like the way this works, then don't use download URLs, and allow only secure downloads via the Firebase SDK. At that point, you are trusting the user they will not take the content and upload it elsewhere and generate a URL to it.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • I'm not giving access to my cloud storage to anyone apart from my website. Also, I've added my website domain to google API HTTP referrers to block access from all websites other than mine. I'm also using the firebase authentication. It all works good on my website, but the problem is when I got networks tab i can see the image download url from firebase and if i copy that image link into a new browser tab it gets displayed...:( – CuriousHash Mar 14 '19 at 08:30
  • Yes, I understand the problem. I'm saying that you can always expected end users to be able to see that URL. – Doug Stevenson Mar 14 '19 at 16:35
0

You seem to have two options as far as I can tell. Unfortunately, they are basically one in the same effectively as you will probably have to implement both.

The first option is to revoke the access token on individual files you don't want to be allowed to download. Unfortunately, this also means that you can't display them anywhere you currently do via the URL as it breaks that link. See this answer for why that is a pain to do.

The second option is to use storage references to download them client side, but this only works if you are using Firebase SDK's in a web app and not a simple static website. I think this shouldn't expose the URL on the network tab of the browser if the app is set up correctly.

You can implement the second option without the first and the URL shouldn't be exposed, but you can't use the url anymore and have to use both options if you implement the first one... :/ meh... firebase is great, but nothing is perfect

Mr.Drew
  • 939
  • 2
  • 9
  • 30
0

This seems to work, I'll update if it doesn't

Edit: "However, the CORS configuration applies only to XML API requests," which one can just go to the file still.. https://cloud.google.com/storage/docs/cross-origin

  1. GCP console >_
  2. pencil icon > create cors.json [{"origin":["https://yourorigin1.com"],"method":["GET"],"maxAgeSeconds":3600}]
  3. go back to shell and enter gsutil cors set cors.json gs://yourproject1.appspot.com

https://stackoverflow.com/a/58613527/11711280

Workaround:

I will make all rules resource.data.authorId, resource.data.members, etc. I need to match the request.auth.uid (or control calls in client code to non-anonymous uid's), and sign-in every user anonymously, at first. Then, uid will not be null when using a firebase initialized from our domain

  • another means to the same ends is of an entirely different route, that is make an on-device keyBox (what I call "RSA") that shares a `device-box` to translate the `account-key`, and thru the `room-box` store a field `saltedKeyArray` of encrypted `room-key`, [reduced-recipients'] `account-box` for each new set of accounted-users `recipients`. That way the content is actually end-to-end encrypted.. IBM is trying to label it as confidential computing or 'clouding' – Nick Carducci for Carface Bank May 11 '21 at 14:28