This question already has an answer here:
Does Firebase App Check discard the need for implementing Security Rules?
(1 answer)
Closed 7 months ago.
Please could I ask for a bit of advice.
I have an app that does not require users to create accounts and does not use authentication. The app stores settings in Firestore.
To secure Firestore, I have set-up App Check and set into enforcement mode for Firetore.
I assume that Firestore is now secure and I don't need any Firestore rules.
Is that correct?
App Check is not a replacement for writing security rules, but rather the two are complementary. While App Check is a great deterrent for abuse, a sufficiently motivated malicious user may still be able to bypass it.
That's why it's recommend to combine App Check for broad protection against abuse and security rules for fine-grained control of who has access to what data.
Related
I am building flutter mobile app that is intensively using firebase services and firestore.
in app start, the app communicates with firestore to retrieve some basic keys and paramaters that app uses in different services, like APIs Keys, IDs, .. etc.
would like to understand if this approach is secure enough? or there is a possibility that communication (firestore query) to be hacked somehow and the keys are stolen?
Note: I am using simple firebase rule that allow read and write if user is signed in using Firebase Authentication
I can indeed hardcode these keys in the app code, however I prefered this database approach to give myself the chance to change these keys if it is changed by the services providers for any reason.
any answers or links are much apprecaited.
You should assume that any value used inside your client-side application can be found by a malicious user and used for their own purposes.
Once someone has those keys, they can call the APIs that require them differently than what your own application code does, unless you use some other means to prevent this such as Firebase's security rules and App Check.
When using security rules, the best way to prevent somebody from doing something different from your application's use-cases is to encode those use-cases in the security rules too. So instead of just requiring someone to be signed in, expand your rules to validate that only the operations that your own code requires are allowed. Use-case by use-case lock it down, until your cod and rules cover the same set of use-cases.
Also see:
Is it safe to expose Firebase apiKey to the public?
google FireStore security hack from web console
I am looking for a way to fetch data to my flutter app which can be adjusted and modified dynamically after deploying the app. As an example, if I want to change the images of the carousel depending on promotions or launch new books to the digital library. I need an economic option to host the data in cloud storage and fetch it from there.
I have considered firebase as well as google drive, but have yet to find a good guide. being a beginner and having concerns about security I want some expert advice if possible.
*edit-
Seeing many a tutorial I assume there is no better way than linking file URLs from the
Cloud Storage. So to dynamically change those is it possible to refer the URLs to some excel sheet fields to obtain URLs. Those fields can certainly be adjusted then without any hard coding. but the question is how to refer to such a sheet file? *
I also want to segregate the users into paid and free users, I have successfully proceeded with the authentication with firebase but still don't understand(I do have some concepts but don't know where to do that) how to put them in groups and impose limitations on them about accessing the data. any guidance, links and helpful advice will be cordially appreciated.
According to what you are looking for, I highly recommend you to use Firebase Remote Config, which is a cloud tool that allows you to modify your app's functionality and appearance without forcing users to download an update. You define in-app default values that control the functionality and appearance of your app when you use Remote Config. Then, for all app users or for subsets of your user base, you may utilize the Firebase console or the Remote Config backend APIs to modify in-app default values.
Your program can control when updates are applied, and it can check for updates regularly and apply them with minimal performance impact.
Remote Config comes with a client library that takes care of essential functions like fetching parameter values and caching them while still allowing you to manage when new values are active and how they affect the user experience in your app.
Here is a tutorial that uses Flutter and Firebase Remote Config that could also help you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I would like to know what is exactly firebase. When i want to create authentication for my app i see on google firebase is often used on flutter for do it but it is not clear what is it exactly. I have a MySQL/php api from the server side and i need to find a way for save on mobile phone an user id when the user create an account, what is the best solution for do that with security. I have seen too, there is people who uses shared preference but security is low i think
Firebase is a whole set of applications and services that acts as a link to Google Cloud, which provides these services. Here's their website.
Firebase is a toolset that (according to them) allows you to “build, improve, and grow your app”, and they give you the tools that cover a large portion of the services that developers would normally have to build themselves. This includes things like analytics, authentication, databases, configuration, file storage, push messaging, etc.
This is different than traditional app development, which typically involves writing both frontend and backend software. The frontend code just invokes API endpoints exposed by the backend, and the backend code actually does the work. With firebase, your app accesses those services directly (or, allows you to write APIs to handle that, if needed)
These are the firebase functions that (arguably) are the most commonly used amongst developers.
Authentication — SECURE user login and identity, with applicable
rules
Realtime Database — realtime, cloud hosted, NoSQL database (older
version)
Cloud Firestore — realtime, cloud hosted, NoSQL database (but with
better queries)
Cloud Storage — massively scalable file storage
Cloud Functions — “serverless”, event driven backend (this is where
you'd write your
APIs)
Firebase Hosting — global web hosting (this is GREAT for flutter
because you can upload your designs immediately without paying for
it.)
ML Kit — SDK for common ML tasks
Here are all their services... but I haven't used most of them.
Finally, the great thing about firebase is that all their functionality is free, and you only start paying when the traffic starts growing.
Is it the best choice for authentication? Without. a. doubt. Not only is it secure, it provides a wide range of side services like "login with your google/facebook/whatever account" and "Forgot your password" retrievals. But it also allows for full token authentication, and access rules.
Sources:
https://firebase.google.com/
https://medium.com/firebase-developers/what-is-firebase-the-complete-story-abridged-bcc730c5f2c0
https://howtofirebase.com/what-is-firebase-fcb8614ba442
as u have api already then what u can definitely use firebase for verifying the phone number of user & then continue him to register that way u can get verified phone number of user.
u dont have to save phone number of user u can get it using
await FirebaseAuth.instance.currentUser().phoneNumber
what shared preference is used for is to store basic info about user like phone number, username, isLogin etc. but if u care about security which i dont think u need to worry about u can use another package like hive which uses AES 256 CBC with PKCS7 padding encryption.
This question already has an answer here:
Why is it okay to allow writes into Firebase from the client side?
(1 answer)
Closed 3 years ago.
If I use the prod environment variables in my App and set the server side rules for Firestore, would my app be completely secure to perform CRUD and authentication? I am asking this because I have been seeing Angular tutorials by pretty famous YouTube content creators (Fireship) and they do not touch server side code and still show how to make a production applications. All the tutorials use only Angular and some libraries to produce the apps and features but then the console on Google says not to expose the API keys. Using only client side Angular even in production environment variables exposes the private keys right?
So in short, should I be using Node to CRUD and Auth with Firestore, or server-side rules on the console works safe?
The configuration that you use on the client to get it to communicate directly with Firebase services is does not include a private API key. Much has been said about this in various forums over the past few years. The thing you see that might be labeled an API key is actually public information. It helps the client library locate the project it's working against. The API keys you want to hide are those that exposed direct access to other billed services, including Google Cloud service accounts.
You limit access to Firebase backend services (Cloud Firestore, Realtime Database, Cloud Storage) using security rules to determine what a user can or can not do with the data stored in it. If you don't do this correctly, you could have problems.
Whether or not you want to let the client access the services directly or make the client go through some middleware you write should be decided by other reasons, as discussed in this article.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We all know that Meteor offers the miniMongo driver which seamlessly allows the client to access the persistent layer (MongoDB).
If any client can access the persistent API how does one secure his application?
What are the security mechanisms that Meteor provides and in what context should they be used?
When you create a app using meteor command, by default the app includes the following packages:
AUTOPUBLISH
INSECURE
Together, these mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools (development purposes only), but typically not appropriate for production applications. When you're ready for production release, just remove these packages.
To add more, Meteor supports Facebook / Twitter / and Much More packages to handle authentication, and the coolest is the Accounts-UI package
In the collections doc says:
Currently the client is given full write access to the collection.
They can execute arbitrary Mongo update commands. Once we build
authentication, you will be able to limit the client's direct access
to insert, update, and remove. We are also considering validators and
other ORM-like functionality.
If you are talking about restricting the client not to use any of your unauthorized insert/update/delete API, thats possible.
See their, todo app at https://github.com/meteor/meteor/tree/171816005fa2e263ba54d08d596e5b94dea47b0d/examples/todos
Also, they have now added a built in AUTH module, that lets you login and register. So its safe. As far as you are taking care of XSS , Valiations, client headers etc.
but you can anyday convert meteor app into fully working nodejs application by deploying to node. So if you know how to secure a nodejs application you should be able to secure meteor.
As of 0.6.4, during development mode, is_client and is_server blocks still both go to the client system. I can't say if these are segregated when you turn off development mode.
However, if they are not, a hacker might be able to gain insight from the system by review the blocks of if(Meteor.is_server ) code. That particularly concerns me, especially because I noted that I still at this point can't segregate Collections into separate files on client and server.
Update
Well, the point is don't put security related code in an is_server block in a non-server directory (i.e. - make sure it is in something under the /server .
I wanted to see if I was just nuts about not being able to segregate client and server Collections in the client and server directories. In fact there is no problem with this.
Here is my test. It's a simple example of the publish/subscribe model that seems to work fine.
http://goo.gl/E1c56