Five tips to secure your app (Firebase Summit 2018)
Why Stack Overflow recommends it
Stack Overflow users, especially Firebase team member Frank van Puffelen, link it when answering questions about Firestore security rules, custom claims timing, and why client-sent data can't be trusted.
Recommended by 5 people across 7 different months, 2018 to 2021.
What it is
A 25-minute Firebase Summit 2018 session by Mike McDonald and Todd Kerpelman on securing Firebase apps. It covers common threat models, writing Security Rules (including schema validation), least-privilege IAM, and where custom claims fit for roles.
What people said
Recommends Brian M. Hunt · 2018-11 · Stack Overflow · on “Running Firestore local e.g. for testing”
Update 2020: There's now also a Firebase Emulator Suite [LINK] . Update Nov 2018: Local emulation, at least for the purpose of testing Firestore rules, was demoed at Firebase Summit 2018 [this video] using @firestore/testing [LINK] and documented under Test your Cloud Firestore Security Rules [LINK] . It looks like it's along the lines of: const firebase = require(`@firebase/testing`) const app = firebase.initializeTestApp({ projectId: 'my-project', auth: { uid: '123', email: 'name@domain.com' } }) const attempt = app.firestore() .collection('colId').doc('docId').get() firebase.assertFails(attempt) firebase.assertSucceeds(attempt) It seems early-on, as it's not been noted in the release-notes, bu
Recommends Renaud Tarnec · 2018-11 · Stack Overflow · on “If don’t allow user to update document in firestore then it will also not allow set with merge?”
One way would be to "validate your schema" with Firestore Security Rules. Watch this video from the Firebase Summit 2018 and in particular Tip #3: [this video] So following the video, you would do something like: ...... allow update: if request.resource.data.size() == 3 && request.resource.data.project is string && request.resource.data.project.size() > 1 && request.resource.data.project.size() < 64 && request.resource.data.userName is string && request.resource.data.userPreferredColor is string ....
Recommends Frank van Puffelen · 2018-11 · Stack Overflow · on “How to use a Firebase app without google_services.json?”
Is it save to send the google_services.json as well? The google_services.json contains the configuration data that your app needs to find its Firebase project on the servers. Is does not automatically allow access to the project though. If I'll send the [ google_services.json ] file, will he be able to see all my databases? That depends on the security rules of your databases. If you've set them to be publicly readable, then your friend will be able to read/write to them. But so will everyone else who happens to discover the URL/ID of your project. To prevent that you'll want to set specific access rules for your databases. To get started on these, I highly recommend reading the documentatio
Recommends Frank van Puffelen · 2018-12 · Stack Overflow · on “Admin functionality for firebase linked app”
Signing in to Firebase Authentication does nothing more than authenticate the user. It essentially verifies that you are Benny, and that you're not Frank. Any permissions associated with a user come from other places. For example, if you use the Firebase Realtime Database or Cloud Firestore, you have server-side security rules that can enforce that the user can only access data that they're authorized for. In your case you want to allow only some users to use the admin app. For that I'd consider using custom claims [LINK] . With this approach you add a custom claim to the profile of the admin users. This is simplest to do from a trusted environment with the Firebase Admin SDK. For example, i
Recommends Frank van Puffelen · 2019-01 · Stack Overflow · on “Is there any function in User Authentication for User Roles?”
Great answer Dennis! Also be sure to check out five tips to secure your app [this video] , and episode 6 in the "Getting to know Cloud Firestore [LINK] video series.
Recommends Frank van Puffelen · 2019-01 · Stack Overflow · on “How to let specific API to run write/read requests on firestore?”
only my API make these requests This is not possible with a Cloud hosted API like this. Since any client must be able to make such calls, all configuration information must be present in the client that you ship to your users. And that means that a malicious user can take that configuration data and make their own (equivalent or very different) calls. Adding a custom header (if possible) would also not help, as they could just as easily get that header and use it in their own requests. So while there are good use-cases for adding additional data to the request, added security isn't one of them. What you can (and should) do is validate that any data written to your database conforms to the bu
Recommends Frank van Puffelen · 2019-02 · Stack Overflow · on “Firebase custom claim how to set?”
The claims on the client are populated when the client gets an ID token from the server. The ID token is valid for an hour, after which the SDK automatically refreshes it. By the time the Cloud Functions auth.user().onCreate gets called, the client has already gotten the ID token for the new user. This means that it can take up to an hour before the client sees the updated claims. If you want the client to get the custom claims before that, you can force it to refresh the token [LINK] . But in this video [this video] our security experts recommend (that you consider) using a different storage mechanism for claims that you want to be applied straight away.
Recommends Frank van Puffelen · 2019-03 · Stack Overflow · on “When a Firebase user is deleted from Firebase console (after user login), it is not reflected in the application”
When a user signs in to Firebase, they get an access/ID token that is valid for an hour. This ID token cannot be revoked, as that would require Firebase to perform a quite expensive check on each call. So when you delete the user's account from the console, they may retain access for up to an hour, at which point they will need to refresh their token, which will fail (since you deleted their account). So their access will automatically disappear within an hour. A few points: If you want to lock the user out of the application before their ID token expires, you'll want to keep an additional list of banned UIDs somewhere. For example, if you're using a Firebase database, you can keep a global
Recommends Todd Kerpelman · 2019-03 · Stack Overflow · on “can I give a web client access to the database?”
Yes. It's totally normal and expected for your web client to have a Firebase API key and be able to access the database directly. As you noted, you're generally relying on security rules to make sure people can only access certain data, as well as make sure that documents written to the database are consistent. For what it's worth, I'm a fan of the mixed-access policy you're talking about -- especially when it comes to more complex write that might span several documents in the database. It's sometimes easier to keep a separate "pending user writes" collection in your database, and then have a cloud function do more of the heavy lifting of propagating that action throughout your database. If
Recommends Frank van Puffelen · 2019-04 · Stack Overflow · on “Possible to change Firebase callable Functions data on Front End?”
Anything you pass from the client to the server, can be changed by a malicious user. That's why you should never trust any data that comes directly from the server. The solution is to only pass the itemID from the client, and have the server look up the price based on that. If the malicious user passes a different item ID, they'll just be buying a different item, but still at the price that you have set. I highly recommend watching Five tips to secure your app [this video] from the Firebase Summit 2018 for more tips on securing your app.