I am building a web application with flutter and I am using firebase's Authentication ,Firestore, and Storage.
my question is, do I have to show the "accept cookies" alert to my users?
That's an interesting question. I am also building a flutter web app with Firebase as the backend. What I know is that, when your application targets EU you need to provide a privacy policy and a cookie consent manager if you use firebase.
The interesting thing is that Firebase stores the cookies in a indexed Database so when you use a cookie scanner there are no cookies found (at least in my application). But as Firebase stores data in theses indexed Databases locally in the browser you need to inform the user about this otherwise it is not compliant with the GDPR.
There is also a problem that Firebase Auth only uses servers in the US, you need to inform the user about this because they have other privacy standards then the EU.
What I also recommend is that you anonymize all the data collected via Google Analytics in the Firebase console because of the GDPR.
If I was you I would make a banner that says "We just use necessary cookies bla bla" and an accept button next to it.
And link your cookie policy.
But I need to say I am not a lawyer so this couldn't be enough. If you have other information about this please inform me.
It all depends on you, whether you want to show it or not.And once it is enabled it will be for all the apps.
Related
Disclaimer: I am new to mobile app development and have little to no knowledge on authentication systems
Normally, when my mobile app makes https calls to my backend server, I know that I cannot trust that these calls to my server came from my app, as anyone can make https requests to my backend server. Even if I give the app a secret key, it is still possible for a hacker to obtain the key and include it in https requests. Therefore, I will not allow https requests to accomplish whatever it wants on the server; rather, I will limit the request to doing only what a user can normally do with their own data – delete their OWN posts, edit their OWN profile, and so on.
Does Firebase work the same way? I saw this StackOverflow thread regarding OAuth consumer secrets, and how they can be compromised and used to imitate a mobile app.
Is this also the case for Firebase?
Can a malicious user theoretically obtain whatever keys/secrets Firebase gave to my mobile app, and use that to emulate requests from my app to Firebase? For example, could they create new users and cause de-syncing issues with my own backend database?
If so, how can I prevent it?
Thanks.
Does Firebase work the same way?
Firebase works in whatever way you program it. Normally you do not put private keys in software that you distribute to end users. The recommended approach is documented very well - use Firebase Auth ID tokens to indicate who is making the call, and use code on your backend to figure out if they should be able to do the work they are requesting. This is what happens with direct database access from your app, but you have to write security rules to protect data according to your requirements.
If you are passing tokens yourself to your own backend, it is up to you to revoke any refresh tokens that you find to be compromised. You cannot fully stop hackers from compromising a system that stores user tokens on devices that you don't control. All you can do is make it hard for them to do so.
Can a malicious user theoretically obtain whatever keys/secrets Firebase gave to my mobile app
Yes, that's why you don't put secrets in code that you distribute to end users. The Firebase config that you're asked to add to your app is not considered private.
See also:
Is it safe to expose Firebase apiKey to the public?
BACKGROUND INFO
I have developed an application in R through the shiny package, and deployed it online through the shinyapps.io service.
Among its different functions, the shiny app can send emails (through my personal Google Account) to users if the fill a form. The emails are sent through the functionalities of the gmailr package, and to make it work I had to follow the procedure on the Google Cloud Platform to create a JSON token, configure the OAuth consent screen, and store the credentials I obtain in a folder of my R project. All the steps to this process are reported at the end of this GitHub issue I opened a while ago.
THE PROBLEM
The JSON token I generated on the Google Cloud Platform expires after some days.
After googling around, I noticed that this can happen if my "Application", on Google Cloud, is still in the Testing phase. First question about this statement:
What does it mean when Google refers, on the OAuth screen, as an Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
In addition, on the Google's OAuth consent screen, I now have the possibility to "publish" such application. If I do that, the status changes as In production, and this message is displayed. Other questions:
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
What will happen to users that try to connect to my application?
Are my credentials, as for example the JSON file, safe?
I know that there might be a lot of confusion in this post, but I am relly not an expert in this field, and so I am worried to make some mistakes.
Thanks a lot for your help!
The GMail API, OAuth and all, is typically meant to allow your app to send email on behalf of any user. It seems your use-case is a little different - you only ever need to connect one user: your own.
What does it mean when Google refers, on the OAuth screen, as an **Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
I think you mostly answered this yourself in your further questions. Google thinks you're building an app that any GMail user can connect to, and so for security reasons, they want to differentiate between a test app and a production app. They don't necessarily know whether or not your app is published on shinyapps.io.
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
I alluded to this earlier, but the GMail API is intended for apps that allow any GMail user to connect and manipulate their own email. Imagine a third-party email client, or similar. Again - Google's wording sounds a bit odd wrt your app since it doesn't fit that bill.
What will happen to users that try to connect to my application?
If you don't explicitly host your own server that implements OAuth with Google, then nobody can even try to connect. As long as you don't leak the shared secret from your Google Cloud Platform entry, you're safe.
Are my credentials, as for example the JSON file, safe?
Probably anyone with the JSON file can send email on your behalf. Marking your app as 'in production' will not change the security implications of your JSON file.
Unfortunately, Google has pretty tight security around their APIs nowadays. If you want to mark your app as "in production" you might open up a can of worms regarding "restricted scopes" (sending email counts as restricted). However, since you're using the JSON file instead full OAuth, I'm not sure if this applies to you. To my knowledge, you should be safe to try marking your app as "in production". Worst-case scenario, you might be able to weasel around the strict verification requirements by saying your app is "internal":
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
I'm developing a mobile app using Firebase and its email authentication feature. I found that there are some unknown sign up with email with 21cn.com domain even though I'm not publishing the app yet. It seems like these email addresses are related to this website(https://mail.21cn.com/w2/).
Is there a way to prevent these unknown signup from outside or how can I improve the project safety?
I was looking around even in my projects and it is not possible to audit who and/or how added the accounts for Firebase Auth (not even in the Activity logs in the GCP Project associated with your Firebase Project)
So, if you don’t know those accounts, I’d suggest deleting them. Also, if the app is not yet published, maybe someone else (if more users are implied in the project) added those accounts directly to Firebase Auth.
Also you may want to change the password of your account.
In general the security of the Firebase Console is up to you.
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.
Can somebody else get the Firebase credentials from my APK and use them? Is this prevented by adding the SHA-1 keys for Android?
If it is prevented, what do I need security rules for since only code from my app with my SHA-1 can manipulate database at all?
If it is not prevented, can somebody else use my Firebase database as long as his requests fit the security rules? (Write 2nd client, which actually cannot do bad things but should not be allowed at all.)
Im not sure how I should think about security rules:
A) Protecting data against access and manipulation from bad guys + B?
B) Just a set of rules to keep data in a certain state and prevent my software from doing invalid database request?
A Firebase Database can be accessed via the REST API, or any of the client libraries. The decision about whether a client can or can't do something is entirely based on the rules.
You can even just access the Database URL in a web browser and see a JSON response by putting .json on the end, e.g. https://[YOUR_PROJECT_ID].firebaseio.com/.json
So the answer is definitely B! The default rules in a new Firebase project are that read and write to the database require auth, but you can configure them to provide whatever levels of protection you need.
Take a look at the Database Rules quickstart to see what you can do!
We don't ship the Realtime Database secret (or any other "secret" material) in the json file that gets baked into your app. That file simply contains resource identifiers that allow us to know which resources (database, storage bucket, analytics, etc.) to properly authenticate to (we use Firebase Authentication for these purposes), and we handle server side authorization to ensure that users are properly logged in.
If you are authorizing your requests properly (using Firebase Realtime Database Rules, for instance), your data is secure!
I'd recommend watching The Key to Firebase Security, one of our I/O talks, which talks in greater detail about how this works.
firebaser here
Thanks to the new feature called Firebase App Check, it is now actually possible to limit calls to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security that Mike and Ian describe in their answers, so that you have another shield against abusive users that do use your app.