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.
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 have a Flutter app (still in development) that currently uses Firebase for the backend. More specifically, I use Firebase Authentication, Storage, Cloud Functions, Firestore and in the future I am willing to use Remote Config, Dynamic Links, Cloud Messaging and more of Firebase's features.
I got to a point where Firestore is not enough anymore for my purposes: Full-text search, geographical querying and advanced queries in general. I know that I can use 3rd party services like Algolia for this but It's too expensive and I wanted something already integrated with my database.
I was thinking of start using MongoDB as my database (while keeping all other Firebase services) but before I do that I need to understand what is the best way to do it.
Can I host MongoDB on Firebase Hosting (I don't know if this possible at all?) or just use MongoDB Atlas and access it directly (See my next question) from my application?
What is the best way to connect my application to MongoDB? From the app directly (using Rest API) or using Firebase Cloud Functions (so I won't expose my database)?
Can I use Firebase Authentication tokens to access MongoDB or do I have to use MongoDB's authentication service?
If there is more things I need to consider before I start switching to MongoDB please point it to me.
Firebase Hosting is a CDN for hosting static websites. So it is not possible to host an application like MongoDB server. You can't host MongoDB on any Firebase services. You have to deploy it somewhere else. There are several options. You can either get a VPS and install MongoDB server on it. But you will have to manage your own DB which can be difficult and can take quite some time. Another option is to use a Cloud Database like MongoDB Atlas. This is a faster and more secure solution. However, pricing can be high. So you have to decide depending on your needs.
Once you have a running MongoDB server, you need to write an API for client apps to communicate securely. Client apps should never talk with a DB instance directly. In this case you can use Firebase Cloud Functions to create an api.
You can use Firebase Auth service with Firebase Cloud Functions. You should have a look at the Firebase Callable Functions which can pass auth context to the function body. Here you can just ensure the user is authenticated or perform some access control logic depending on your authorization needs.
Overall, you are going to add an another layer to your architecture. It is possible but will take your time to set things up and you will loose some firestore benefits like offline persistency.
Background:
I'm building an API service app. The app is just like any other, you send an HTTP request and receive a response. This seems simple up until I start thinking about user registration, payments, authentication, logging and so on.
Application:
tl;dr simple app diagram
Endpoints listening for HTTP requests and doing all the request related work. This is the core of the service, what the service user would use this app for. Directly not accessible to the end user (unless somehow it knows the url). Python flask server, deployed on google cloud RUN.
API gateway acting like a proxy and a single access point forwarding the requests to the endpoints. This is the service access point for the end users. This part will also be responsible for authentication, limitations, logging and tracking the use of the API endpoints. Python flask server, deployed on google cloud RUN.
Website including documentation, demo and show off of API calls through API gateway, registration, payment (thinking of Stripe) etc. VueJS app on NodeJS server on google cloud compute VM.
Database storing credentials of registered users, payment information and auth keys. Not implemented yet.
Problems:
Is this architecture proper? What could be done differently or improved? How could I further simplify all the interactions between separate parts of the app? Am I not missing any essential parts?
Haven't yet implemented the database part and I'm not sure what should I
use? There are plenty of options on google cloud. Also I could go with something simple and just install a DB with http/JSON interface on google cloud compute VM. How do I chose the DB? Given such an app, what would be the best choice?
Please recommend literature/blogs/other sources of info on similar app
architecture for new developers not familiar with it?
This is pretty open ended, but here are some general comments:
Think about how your UI will work. Are you setting up a static app served directly from cloud storage or do you need something rendered on the server? Personally I prefer separating UI from API when I can but you need to be aware of things like search engine optimization. Even if you need to render some content dynamically your site can still be static. Take a look at static site generators like Gatsby. I haven't had to implement a server rendered UI in years and that makes me happy.
API gateway might be fine, but you don't really need it for anything. It might be simpler to start without it and concentrate on what actually matters. If your APIs are being called by an external client you can't trust the calls anyways and any API key you might be using will be exposed. I'd say don't worry about it for a single app. That being said, if you definitely want to use a GW then use one, just be aware that it is mostly a glorified proxy and not some core part of your architecture.
Make sure your API implementations don't store any local state so you can rely on Cloud Run scaling your services up and down. Definitely don't ever store state directly inside your containers. If you need state on the server it needs to be in some external data store.
Use JWTs or an external IDM (that will generate JWTs) for authentication. Keep session data on the client side as much as possible and pass the JWT in every API call to authenticate the caller. If you are implementing login on your own the only APIs you need to expose without tokens are for auth and password recovery, which you can separate into their own service.
Database selection depends on how well you understand your processes, how transactional your services are and your existing skillset. Overall I would use what you are comfortable with, you can probably succeed with a lot of things. Certain NoSQL flavors can seem simple on the surface but if you don't have a clear understanding on the types of queries you need to run they can get tedious to work with. Generally you should stick to relational databases for OLAP style implementations and consider NoSQL for OLTP. Personally I like MongoDB and it is very popular, probably because it sort of sits in the middle of the pack which makes it fit a lot of applications. Using MongoDB also makes you cloud agnostic since it is available on every platform. Using platform specific database flavors can lock you down to a specific vendor.
Whatever you do, don't start installing things on VMs. You can be almost 100% sure you are doing it wrong if this comes up. Remember, the services you consume don't all have to be managed by Google or even run on GCP. You can get MongoDB capacity directly from MongoDB who manage it on your behalf on all of the Big3 cloud vendors.
At least think about the long term, even if you don't necessarily need to have it impact your architecture right now. If you are expecting your app to be up for years try to make it more platform agnostic than less. This might mean sticking away from some really platform specific serverless features that will force you to jump a couple of extra hoops. If you are using Cloud Run you are using containers which already makes your app pretty portable, don't lock it to one platform by using a lot of platform specific features. That being said, don't stay away from them either. You should always go for the low hanging fruit, so don't try to avoid using things like secrets manager etc. If your app has a short lifespan and you need really fast time to market then don't worry about it.
Just my 2c, what you are doing is very generic and can be done in a lot of different ways.
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.
I'm pretty new with an Ember so for the start I have a noob question - is it possible to use Local Storage and REST adapter at the same time?
For example, if I want to do a login via API, if login is success the server will return an API key which is used for later communication with a service. Is it possible to store that information locally on the client and to retrieve it when necessary but also, for other models, to use REST adapter?
If this is not a good way to handle such case, which one would you propose and is there any kind of example which would me lead me in the right direction?
Thanks to the people from #emberjs, I found out that there is a wonderful ember-auth authentication framework for the Ember.js which does what I need.