Is Google-Services.JSON Safe from Hackers

Should I add the google-services.json (from Firebase) to my repository?

A google-services.json file is, from the Firebase doc:

Firebase manages all of your API settings and credentials through a single configuration file.

The file is named google-services.json on Android and GoogleService-Info.plist on iOS.

It seems to make sense to add it to a .gitignore and not include it in a public repo.

This was discussed in issue 26, with more details on what google-services.json contains.

A project like googlesamples/google-services does have it in its .gitignore for instance.

Although, as commented by stepheaw, this thread does mention

For a library or open-source sample we do not include the JSON file because the intention is that users insert their own to point the code to their own backend.

That's why you won't see JSON files in most of our firebase repos on GitHub.

If the "database URL, Android API key, and storage bucket" are not secret for you, then you could consider adding the file to your repo.

As mentioned in "Is google-services.json safe from hackers?", this isn't that simple though.

baueric asks in the comments:

In that post he says:

The JSON file does not contain any super-sensitive information (like a server API key)

But the google-services.json does have entry called api_key.

Is that a different api key than a "server api key"?

Willie Chalmers III points to "Is google-services.json safe from hackers?", and adds:

Yes, that API key isn't a server API key which should never be public, so it's fine if your google-services.json is visible by others.

In any case, you should still restrict how your client API key can be used in the Google Cloud console.

---

As noted by Puzz in the comments, see also "Is it safe to expose Firebase apiKey to the public?"

In that answer, Frank Van Puffelen mentions:

Update (May 2021): Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to the backend services in your Firebase project to only those coming from iOS, Android and Web apps that are registered in that specific project.

Google services json file for github actions?

Well... I have found the solution but in case if anyone needs I am explaining here.

We can store the content of google-sevices.json in Environment variable (aka Secrets in github). Actually github uses linux based cli so we have to execute some command on the cli using github actions.

There will be two steps ...

• Firstly create the google-services.json file in base64

- name: Create file
  run: cat /home/runner/work/<Project-Name>/<Project-Name>/app/google-services.json | base64

• Then put data in the file (basically this fetch data from github secrets and put the data in json file before building the application)

- name: Putting data
  env:
    DATA: ${{ secrets.GOOGLE_SERVICES_JSON }}
  run: echo $DATA > /home/runner/work/<Project-Name>/<Project-Name>/app/google-services.json

• Then define the content of google-services.json file in the github secrets via: Setting > Secrets > New Repository Secret using name GOOGLE_SERVICES_JSON

Both of these commands should be placed before the gradle build command in gradle.yml

By doing this your google-services.json file will be created and has data also so the app will build successfully.

How Secure is Firebase Real-time (Online) database for Android?

Welcome to the joys of what effectively is a two tier system. You can do several things to protect your data - but not for free.

First some facts:

1. He who has the credentials to the database can access it
2. if the app can access the data, then your database credentials are effectively available to anyone who can extract it from your app

There are counter measures that can raise the bar for an attacker, but a determined (or lucky) attacker can get access. And if he has access it is very difficult to prevent him from doing damage because e.g. changing the DB credentials will also force all of your users to update.

What you could do is

1. decide that protecting the data is not worth the effort and that you/your management can live with the risk (but then you‘d have a decission and are done)

2. Use the firebase ACL as you already did. To create user specific „depots“ use per user nodes (see below, it won‘t render code here). The configuration happens in the console.

3. Build business logic on a server and place all credentials there. This will ensure that you have full control

4. prevent the apps from reading the data in plaintext. Use public key algorithms to encrypt the data. Keep the private key on the systems that has to read the data. Then the app cannot read the data in plain (but still e.g. find out how much you have and what the rate of change is). This also will not prevent manipulation or deletion of data.

Example ACL:

// These rules grant access to a node matching the authenticated
// user's ID from the Firebase auth token
{
  "rules": {
"users": {
  "$uid": {
    ".read": "$uid === auth.uid",
    ".write": "$uid === auth.uid"
      }
    }
  }

---

Related Topics