Security Rules
Firebase Storage exposes quite a bit of functionality to the public, so you'll need to write some security rules.
Like Firestore, Firebase Storage uses Firebase's new security rules syntax.
The best way to understand Firebase Storage security rules is to read up on Firestore security rules. They're basically the same.
The basic rules look something like this:
// Only authenticated users can read or write to the bucket
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Let's break these rules down line-by-line.
service firebase.storage - defines the service, in this case it's firebase.storage
match /b/{bucket}/o - defines the bucket; the
{bucket} clause indicates that these rules apply to all Cloud Storage buckets on the projectmatch /{allPaths=**} - creates a new rules block to apply to all paths
allow read, write: if requests.auth != true ; - allows read/write access for all authenticated sessions
Of course, instead of matching collections and documents, you're matching folders and storage objects. But that's the only difference.
Let's write a match block for a folder structure like this:
/user/{userId}/path/to/file.txtservice firebase.storage {
match /b/{bucket}/o {
match /user/{userId}/{allPaths=**} {
allow read, write: if request.auth.uid == userId;
}
}
}
And, like Firestore, match blocks can be nested... if you need it.
Firebase Storage security rules tend to be a bit simpler than Firestore's.
Firebase Storage supports
read and write. That's it. This is a break from Cloud Firestore which supports other sub-types. In this case you're either reading or writing.Wildcards work just like those in Firestore. You can place them at will and override them as needed. You'll also want to be careful to use the
{someWildcard=**} syntax when you want your rules to cascade; otherwise, they won't apply to nested folders.The following example secures a dropbox-style pattern where users can upload to an uploads folder at
/user/uploads/{userId}/uploaded-file.jpg but can only read from /user/thumbnails/{userId}/thumbnail.jpg.service firebase.storage {
match /b/{bucket}/o {
match /user/ {
match /thumbnails/{userId}/{thumbnail} {
allow read: if request.auth.uid == userId;
}
match /uploads/{userId}/{upload} {
allow write: if request.auth.uid == userId;
}
}
}
}
Rule conditions have access to a
request object that represents that incoming request. You'll be using the request object for most rule conditions.The fields of most interest are
request.auth.uid and request.auth.token, which contains the user's JWT.Rule conditions also have access to a
resource object. In Firestore this object refers to the pre-write state of the document, but in Firebase Storage this is the object being uploaded, downloaded, modified or deleted.Here's a sample
resource object that you may find handy:{
"name": "howtofirebase/uploads/locked-mode.png",
"bucket": "quiver-four.appspot.com",
"generation": "1517664154693678",
"metageneration": "1",
"size": "138099",
"timeCreated": "2018-02-03T13:22:34.676Z",
"updated": "2018-02-03T13:22:34.676Z",
"md5Hash": "Yzg3ZGNlZDVjODZiYzAyNGU4NTljYTU2MDdlZDMwMjk=",
"crc32c": "QK5Kyw==",
"etag": "CK7g0MbridkCEAE=",
"contentDisposition": "inline; filename*=utf-8''locked-mode.png",
"contentEncoding": "gzip",
"contentLanguage": "en",
"contentType": "image/png",
"metadata": {
"firebaseStorageDownloadTokens": "c7dfc4c3-0d91-4e1a-b6a1-d4e03a320ef1"
}
}
It's been said before and we'll say it again. Read the docs.
The highlights:
Last modified 5yr ago