I'm building a production hybrid mobile app that uses Firebase/Firestore. Since it's a hybrid app, I can not use the bundle ID or HTTP referrer methods to restrict the API key (Google support confirmed this is not supported).
My worry is that anyone could decompile the app and get the API key, using it with a simple Node.js script locally, and access my database.
Node.js scripts can bypass all Firestore rules, making unrestricted API keys very powerful. So far I have been unable to find a way to restrict keys with hybrid apps, including reaching out to Google support. I'm wondering if the only way to actually achieve firebase/firestore security is to use Native apps vs. Hybrid?
Actually for ios, we are not able to restrict the google api key. But, for android we have done with HTTP referrer method only.
For android it is possible.
If you are using ionic4, Please use the same origin value whatever you set in you config.xml corresponding to you android app.
Related
I just got a mail from the Firebase support that my current API key restrictions for the Firebase API key lead to malfunctions for the Firebase Installation API. Since, I have a web application and not an iOS or an Android app, I´m assuming that this is not a real issue for me at the moment.
However, this got me wondering if I enabled all necessary HTTP referrers (websites) in the Google Cloud Platform to ensure a working environment for my web application. Let´s say my domain is called www.domain.com and my Firebase project is called projectx. I currently have these two entries in the HTTP referrers for the Application restrictions:
www.domain.com/*
projectx.firebaseapp.com/*
Is there anything else I should enable? Because I saw that Firebase also enables multiple domains such as projectx.web.app by default.
It's fairly simple: you need to enable the domains that your app uses.
The two domains you have are the defaults for cases where you have a common domain:
www.yourdomain.com/* is the custom domain that you typically share out with people.
projectx.firebaseapp.com is the default domain generated by Firebase, and is typically also used in sign-in screens (although you can change this).
You may also want to add:
projectx.web.app, which is a newer default domain that Firebase creates. But this is not required, so only add it if you expect to hand it out to folks.
localhost, which is handy for local testing
I received an alarming email from Google a couple of days ago stating that:
[Action Required] Firebase services for your application are malfunctioning due to Application restrictions
I have a Vue based website that uses Firebase for Authorization of users and storing files they are uploading. When I configured the API key that I set up, I restricted this key on the application level, to only work from the address of my website.
I did not impose any API restrictions - Under API Restrictions the radio button with Don't Restrict Key is marked
Having said that, when I try to use my website, I get the following error:
[403] Requests from referer [WEBSITE] are blocked.
The email I got from Google stated that:
Firebase SDK updates on February 27, 2020 (Android) and January 14, 2020 (iOS) replaced the Firebase Instance ID service with a dependency on the Firebase Installations API.
As a result, Firebase services like Firebase Cloud Messaging will malfunction for users who installed your app after it was released with updated Firebase SDKs. Additionally, repeated failing requests to Firebase may slow down the end-user experience of your app.
Application restrictions you have applied to the API key used by your Firebase application need to be updated to allow your application to use the API key.
Inside this mail, there were the following instructions:
Open the Google Cloud Platform Console.
Choose the project you use for your application(s). Open APIs &
Services and select Credentials.
Click Edit API key for the API key in question.
Scroll down to the Application restrictions section.
Change the radio button to None, and click Save, or add your
application to the list of allowed Android apps, iOS apps, or HTTP
referrers, respectively.
If the radio button already shows None you may be looking at the
wrong API key.
You can check which API key is used for the Firebase Installations
API by looking at the service usage page for your project.
Since I do not have any API restrictions and there is also no other API key that I have, I don't understand how to solve this situation.
One option that works is having no application restrictions, but I don't think that is the correct solution.
I also tried changing the API Restrictions to allow only the services from Firebase that I am using, but that did not fix the problem.
Any help or direction to a solution, will be appreciated.
I have to build an API using Firebase, and need some help with design choices. I want to be able to sell the API to users, who can then use it to build/integrate their own applications. Users will have both read and write privileges.
General information:
I'm using Firestore db with email & password authentication.
Only specifically assigned users may use the API
Each user may only access specific documents concerning them.
I've noticed 3 different ways in which an API can be provided to a user of my Firestore db:
https triggered cloud functions (https://firebase.google.com/docs/functions/http-events)
Using the SDK (https://firebase.google.com/docs/firestore/client/libraries)
Using the REST API provided by Firbase (https://firebase.google.com/docs/firestore/use-rest-api)
API requirements:
Used only by users that I specifically grant access to (email & password login)
I want to limit these users to only a couple of read/write tasks that they're able to perform.
It needs to be safe.
My current approach is:
Use the 3rd option - the REST API provided by Firebase (thereby giving users the projectId and API key)
Add authorised users to the list of authorised accounts on Firbase, and limit access using custom claims and database rules.
My questions:
It seems that https functions (option 1) are normally used in API building. Are options 2 and 3 unsafe?
What are the normal use cases of the 3 options? When should each be used and when should each be avoided?
Are there any obvious flaws in my choice of option 3?
Any other useful information about making these design decisions will be much appreciated.
Thank you in advance
TL;DL: It depends on what you want to do with this API and how many and what type of devices/users will be calling it.
Before answering your questions I will list below the advantages of each approach:
Cloud Functions:
Cloud Function is a Functions as a Service Solution, so it's also a hosting service for your API, therefore you won't have to provision, manage, or upgrade servers and the API will automatically scale based on the load. Also this option takes into account the pros of SDKs and client libraries, since your code will have to use it to connect to Firestore anyway.
SDKs and client libraries:
This is the easiest and more optimized way to reach Firestore, however, environments where running a native library is not possible such as IOT devices will be left out of your solution, so consider this while implementing this option.
Cloud Firestore REST API:
Every device properly authorized to access Firestore will be able to do so.
NOTE: For both SDK and REST API you will need to consider hosting of your API, either on Cloud Functions, as mentioned, App Engine Standard, App Engine Flex or a Compute Engine Server Instance.
All that being said, it's up to you and your API's usage and requirements to say which option is best considering the points above.
As per security, I'd say that all option can be secure if firebase rules and firebase auth are set correctly.
I developed an app to test the google login feature using flutter and google authentication. The project is a closed project and only I have access to it. But recently I saw that there was a google sign in from an unknown Email ID. How did the user login without the build of my app? Has my account been hacked? What is going on?
Anyone with knowledge of your project's API Keys can access your Firebase Project using simple CURL Commands.
This is why it's a good idea to add restriction to those API Keys
In case you haven't, go to https://console.cloud.google.com and
Select your project
Click the menu icon at the top left (hamburger icon)
Go to API & Services and then credentials
You can view the APIs for your Google Cloud Project (linked to your Firebase Project) and then set restrictions for the API keys, refresh them or restrict access to specific platforms like Android or iOS.
You can also set restrictions on which components of Firebase the API key is allowed to access. For example, if your project doesn't require the use of Cloud Firestore, you can ensure that the API Key cannot be used to make calls to the Firestore Database
All said and done, I would still recommend that you shoot a mail to the Firebase Support team at https://firebase.google.com/support/troubleshooter/contact
To anyone still wondering about this:
If you provide a native google sign in and the registered
email adresses look like this:
karolynmccorkle.91842#gmail.com
normabrock.69306#gmail.com
guillermogeorge.53163#gmail.com
kylegomez.35423#gmail.com
opalbarrett.09499#gmail.com
they are probably test accounts used to generate Google Plays Pre-Launch reports.
You can read about it in the Play Console Help here.
If your app has a sign-in screen and you want the crawler to test the
sign-in process or the content behind it, you need to provide account
credentials.
Note that you do not need to provide credentials if your
app supports "Sign-in with Google,” which enables the crawler to log
in automatically.
I am building a react native mobile application, and I'm using the expo Google and Apple sign in libraries to provide authentication. Both libraries use firebase to authenticate, but my database is hosted elsewhere (heroku while in development, but probably migrating to digital ocean in the future). How can I protect my API using the access tokens I receive from the Google and Apple sign in utilities on my non-firebase server? All the code samples I've seen use firebase as the backend. I want to make sure that all the API calls are authenticated, and that the proper storing/refreshing techniques are used on the client, while maintaining the "persistent session" UX for users so they don't have to sign in every time they open the application.
I feel like I should know this, and I have a few ideas, but really don't want to get this aspect of the application wrong.