FR: Alternative to getDownloadURL that doesn't expose a public download URL

[jhuleatt]

[REQUIRED] Describe your environment

• Operating System version: [all]
• Firebase SDK version: 4.1.3
• Firebase Product: storage

[REQUIRED] Describe the problem

Currently, the only way to get an image is to call getDownloadUrl. The download URL is unguessable but not affected by security rules, which means that once someone has the download URL, they could theoretically use a bot to create a huge number of downloads and run up a big Cloud Storage bill or hit the project quota.

The Android SDK provides getFile, which downloads the file directly to the device. Each download involves a security rules check (source).

Request

Provide a function like getFile that checks security rules every time.

Alternatively, perhaps a function that returns a signed URL (for example, getSignedUrl(expireTime)) could accomplish a similar goal.

[sphippen]

We've been considering something like this for a while. The reason we decided to only expose a downloadURL on web is because of its versatility.

If we wanted to give you a way to download the file checked by security rules, the best we could do would probably be to give you an XMLHttpRequest you could use to download the object yourself. The problem with this is that if you're using an XHR the downloaded data ends up in memory, which means if it's a large file (say, more than a few gigabytes) it's difficult to do anything reasonable with the XHR.

On the other hand, with a download URL, many things are simpler (you can embed it directly in an img tag) and you can give the user the option to download the file (an <a> tag with the "download" attribute, tell them to right click > "Save file as...", etc.).

Of course, it's also easier for anybody to automate abusive behavior if they have a download URL (as you pointed out). At the same time, for a sufficiently dedicated malicious user there isn't a big difference between exposing the download URL vs not exposing it (any user capable of downloading the file via security rules can get a download URL and do anything they want with it). As a result, we don't consider this a high-priority change.

[dinvlad]

Could you clarify (apologies if these questions are better addressed elsewhere):

1. Does getDownloadUrl from FB JS SDK check security rules before generating a link? In other words, is there a reasonable guarantee that a download URL, unless shared, can only be obtained by FB users who have access to the object via security rules? And what's the lifetime of this link?

2. Is it possible to use accessToken generated by FB (with Google auth provider) to access Cloud Storage directly (bypassing FB mechanism for getDownloadUrl), e.g. by using Google Cloud SDK for JS? In which case, do the FB rules still apply? Or do we then need to manage access manually through IAM rules on the affected buckets? In which case, does the accessToken represent their "normal" Google user identity (so we can just add their GSuite email to IAM rules)?

[sphippen]

1. Access to the download URL through the SDK is indeed controlled by security rules. If you don't have read access to the object, getDownloadURL will fail. The link lasts until it is revoked manually in the console.
2. The Firebase accessToken cannot be used to access GCS except through Firebase Storage (which we only officially support through the SDKs). Even if the Firebase accessToken was generated with a Google user login, you'll still have to use the more typical credentials: a service account key, etc., if you want to talk to GCS' APIs directly.

[dinvlad]

Thanks @sphippen, regarding (2) I don't quite understand: if I authenticate with FB and ask for https://www.googleapis.com/auth/devstorage.read_only scope (privacy/app verification issues aside), then I sure am able to access GCS APIs (https://www.googleapis.com/storage/v1/b/...), as I have just verified through Postman. What do you mean then by

The Firebase accessToken cannot be used to access GCS except through Firebase Storage

[sphippen]

Sorry, I misunderstood what you meant by accessToken. I thought you meant the Firebase Auth JWT, but I see you were referring to the accessToken associated with the OAuth credential.

So, if you log a Google user into your app with Firebase Auth and request the https://www.googleapis.com/auth/devstorage.read_only permission, you get the OAuth accessToken back, which you can use to read GCS resources that that user has access to. This access is controlled by the IAM policy (or GCS' legacy ACLs) on the bucket/object you attempt to access.

In which case, does the accessToken represent their "normal" Google user identity (so we can just add their GSuite email to IAM rules)?

Exactly correct.

To summarize, the Firebase Auth JWT lets you access buckets associated with the project in which they were created through Firebase Storage. The Storage security rules are applied to these requests. (third-party auth)

If you log a Google user into your app, they'll click through a page granting you the permissions you request, and the OAuth accessToken will give you those permissions. You can use that token to make requests to GCS' normal API, but only to access resources the user already has access to through Cloud IAM or GCS' legacy ACL system. (first-party auth)

[dinvlad]

Thanks @sphippen! I've tested this approach and it works as you described. Hopefully it will help others as an alternative to getDownloadUrl().

That being said, requesting a devstorage scope is a more blanket permission and since last July Google requires verification of apps that use it. We may end up just using getDownloadUrl(), or (a 3rd alternative suggested by @jhuleatt) getSignedUrl() on the backend. The latter option is better for us because it enables limited-lifetime links. I just wish getDownloadUrl() contained an option to specify the lifetime.