0

I'm preparing to release my app to play store. I made it opensource hoping others will contribute. I'm now working on integrating Crashlytics, but later I'm going to add other Firebase features. My problem is I'm not sure how I should manage the API keys.

  1. Since I want a potential contributor to be able to run and debug my app on their end, I need to keep the Firebase key checked in. As I understand, it's okay to do that with Firebase keys because I can apply restrictions on them. Is this a common thing to do, or what are the alternatives?

  2. Introducing Crashlytics creates a problem with this scheme. I don't want to see crash reports of people who modify the app on their end. My idea is to create a separate key restricted to Crashlytics specifically and keep that one a secret. I'm new to Firebase and don't know if this is even possible though.

I just can't find any resources on that and afraid that I'm doing something weird. What is the common approach to this?

The app is written in Flutter, just in case.

splaytreez
  • 552
  • 5
  • 13

1 Answers1

0
  1. You seem to already have researched this, but I recommend re-reading Is it safe to expose Firebase apiKey to the public?

    If all your app uses from Firebase is Crashlytics, you can keep all other APIs disabled. That way only Crashlytics can be called with the configuration data in your app.

  2. Restricting an API key to Crashlytics won't be enough here, as a malicious user can also only call Crashlytics with their code, which is what you're trying to prevent. What you want here is a way to ensure that only your code can call Crashlytics.

    Within Firebase that is accomplished by a product called App Check, which ensures that only calls coming from your original code on a genuine device are allowed. But there currently is no integration of App Check with Crashlytics yet. I recommend filing a feature request for it.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807