Is it necessary to create Terms and Conditions in an application developed with firebase (Auth, real database and storage)?
I get Mac and email always. If the user want NickName, Social Networks Accounts, age, sex, and interests.
If its necessary, some example?
If you are developing a product that uses Firebase you should be doing a careful read of the Firebase Terms of Service yourself, or seek legal advice on the matter. StackOverflow probably isn't going to be a good place to get advice of this nature.
It is clear from the Firebase documentation that different Firebase products carry their own policies that you should adhere to. You'll need to review the policies of each product. Firebase Analytics, for example, indicates notifications that must be provided to users in the Google Analytics for Firebase Use Policy.
Your users deserve to know how their data is being handled, stored, used, etc. Let them know!
Related
Could someone please explain to me why a bad actor could not create the following disruption for potential new users to my app?
The bad actor:
Obtains a list of emails from the dark web or some other nefarious source.
Acquires my Firebase keys by inspecting my app javascript -- yes my app is minified, but it would still be possible.
inserts malicious javascript code into my app sources on their local browser. The malicious code uses the Firebase sdk and my app keys to create accounts for each email address.
While there is no possibility that the bad actor could gain access to validated accounts;
nevertheless, creating these accounts would generate unsolicited email verification requests to the owners of the emails and it would also interfere with a smooth account-creation experience for those users when they actually do want to signup.
Am I missing something here?
firebaser here
As Dharmaraj also commented: the Firebase configuration that you include in your app is used to identity the project that the code should connect to, and is not any kind of security mechanism on its own. Read more on this in Is it safe to expose Firebase apiKey to the public?
You already in your question noted that creating a flurry of accounts doesn't put user data at risk, which is indeed also correct. Creating an account in your project does not grant the user any access to other user accounts or data in your project yet. If you use one of Firebase's backend services, you should make sure that your security rules for that service don't do this either.
The final piece of the puzzle is that Firebase has many (intentionally undocumented or under-documented) safe guards in place against abuse, such as various types of rate limits and quotas.
Oh, and I'd recommend using the local emulators for most of your testing, as that'll be faster, doesn't risk accidentally racking up charges due to a quick coding mistake, and (most relevant here) doesn't have the rate limits in place that are affecting your e2e test.
Similar questions (eg. this) have already been asked and answered in negative. I'd like to if any alternatives exist.
I am developing an application where users can collaboratively edit a document. I don't want to force every user to login. I would like to allow users with a link to be able to edit a document (similar to what Google Docs allows). I was planning to share a token in the link which when presented would grant write access. I would have stored the tokens in a separate collection and matched them. But as per previous answers this is not possible and a security issue.
I don't consider it a security concern (for my purposes). The token is like a pre-shared key. Whoever presents the key is allowed access. If the owner thinks that the key is compromised, he can revoke the same. Kindly help me with a way to achieve this. I'm also curious to know how other apps like Google docs achieve this.
As Mentioned by #Dharmaraj,
In Firebase security rules, you have 3 pieces of information, namely the path, the data and the token. Except from those three you can't pass additional information in a security rule.
Cloud Functions would be a better fit here, given the flexibility. Additionally, with Cloud Functions you'd not be forced to authenticate users, and still be able to connect to Firestore if needed.
Context: I just got an email which I believe is spam from admin#typingchimp.com saying my auth users accounts can be stolen and asked if there are security bounties. I use firebase auth, and it should be easy to see that checking client side JS code. Although I think it's spam, it leads me to ask:
Are there any known security vulnerabilities or ideal security related settings for firebase auth? Perhaps an article or documentation beyond https://firebase.google.com/docs/rules/basics or https://firebase.google.com/docs/rules/rules-and-auth ?
PS: This is an auth-only question, but yes my Real-time DB restricts read access to the signed in user and doesn't allow write access. No other settings have been changed beyond this. My site uses SSL of course.
I know google limits individual IPs from making a bunch of failed login attempts and will block you temporarily.
I regularly get these types of emails (spam!) indicating that they have already found security flaws, or that they will, for a "finders fee". It is a marketing campaign trying to drum up sales activity.
Firebase Authentication has been designed and is in use by millions of apps. Hundreds of millions (or billions??) of accounts live in Firebase Auth. If there are vulnerabilities with the service, we will learn of it rapidly.
There is the potential that your particular use of Firebase Auth does not follow secure practices. For example, if you have your API keys checked into a publicly available code repository.
However if you follow the (fairly straightforward) "getting started" and recommendations docs from the Firebase team, odds are that your app is just fine.
I have seen a firebase api in which you can create firebase projects and it occurred to me for example, when a user wants to counter a SaaS, make it easier for me to create a project and connect it to their SaaS but I have the following questions:
If there are supposed to be limits to creating firebase projects in a google account, will there be a time when databases can no longer be created for new users?
If the above is true, how can this be solved?
I have seen that you can ask for more projects, but how many can I have?
I know that with firestore, I can model data and only in a database have all the information, but for example, each user may have special requirements in their system and also provide security and information saving operations that would be impossible if all information is in a single database.
Thanks for the help.
EDIT
"How many projects can you have as a developer?" Yes, that's what I mean, having all the user bases in a single firebase google account. For example, on a web page, the user wants to pay for the application, with firebase admin and google cloud functions, I can automatically create a project and have all the databases in a google account. And what I want to know is if you can have multiple databases. I have seen that you can ask google to give you permission to host several projects but, for example, can you have more than 100 projects or even 1000? (I may never have reached that number, but in that case, I would like to know the limits that can be reached).
Edit 2
This first structure I have all the documents in a "universal" collection and I identify them with an id to know the user who used it.
But the second structure seems to me more organized and clean, in addition to the fact that users at no time need to share information among others. I have read that having nested collections is not good but over the years and the progress that firestore has had, this is no longer or was a problem only that the limitation is that you can only have up to 100 collections anidades but I never think to reach that quantity.
Inside of list, have all products for that user, because inside of document, only can have 1 mb of data and download 1 mb and is not the best option.
in the firestore documentation I see that it does not reveal other problems, it only says that it is difficult to delete the subcollection, but I do not allow users to do that and if I need to delete the subcollections, with the Google Cloud functions i can do it.
So, the second structure is more intuitive for me, but is the best option for that? or actually firestore is not good for this strcucutre?
I am developing a platform that involves DialogFlow (CHATBOTS) with different types of integrations (Whatsapp, Facebook, twitter, etc.).
That is solved, since it has its own ecosystem.
The problem is that I need to model in firestore to store user interactions with the BOT.
When a user begins an interaction, it remains in the entire conversation through a SESSION attribute.
The data I get is:
userSay,
agentResponse,
agentResponseId,
intentDisplayName,
intent,
createdAt,
session,
platform.
With some variation or extra attribute depending on the platform where it comes from (WhatsApp, Facebook, Telegram, etc)
The storage of these records is merely by way of consultation and reports and metrics, to offer substantial information to whoever uses the platform.
I would love to be able to guide me, thanks.
Here is a guide for getting started with Firestore, in case this would be your first time using it.
For this specific use case, the implementation could be done by using a Cloud Function which would receive and parse the request payload from Dialogflow, and update the Firestore database. Webhooks will fulfill the Dialogflow Intents, which are used by the function. Here is a tutorial using this approach, and here is another one.