0

I have some concerns about using Firestore directly from mobile clients. I saw that with Firestore, mobile app is controls to db directly. There is only db side control is rules. However I am not yet understand how can I resolve my concerns. I worrying because with decompiling app or any other ways maybe someone can access maliciously.

To resolve my concerns and improve the security I want to:

  1. Limit access per time for user. For example if some one writes or reads db 30 second ago I want to block their access until 1 minute. Especially it is important for writing.
  2. I want to have the only document owner write their documents and block others to write. For do this I don't want to store owner id in same document because if I put this information to there, readers can receive this information and maybe some way they can write request with this information.

In summary, I want to prevent malicious and excessive requests exceeding limits. I want to avoid the risks in db side. How can I resolve my concerns in the two above matter?

Scenerio:

Think that there is harmful someone with name X. X knows how to decompile mobile app or maybe knows how to request my application's firebase Firestore account (maybe watched communication I don't know). X wants to harm my application. First X watching communication and if we give owner userid in document X receives needed information so sending request with changing his/her userid or auth.uuid. Secondly X wants to disable firebase of my application. For do this X sends too much requests. The limit is overs due to too many requests. Note that: I am using Firestore directly with mobile application. There is no web service to communicate.

How can avoid this scenario?

Gokhan Alp
  • 61
  • 5
  • The first one is not possible with security rules. The second one is possible. If you have tried implementing it but it's not working for you, you should edit the question to show what you tried, explain your database structure, and state what isn't working the way you expect. – Doug Stevenson Jun 06 '19 at 19:37
  • @DougStevenson A limit on write throughput would actually be possible with security rules, wouldn't it? Have rules validate that each write operation contains a write to a known location with the server-side timestamp? Or can't we ensure that? – Frank van Puffelen Jun 06 '19 at 20:19
  • I don't have code for second one. But I saw some examples that user id used as document or a as a field in document. And saw some usage like resource.data.userId == request.auth.uid .. I think in some way maybe auth did can be changed. If third person, who is not owner of the document and should not change the document, knows document userid maybe they can modify to db document? I think that this is risky isn't it? Example took from there: https://itnext.io/setting-up-cloud-firestore-security-rules-1ad24438805a – Gokhan Alp Jun 06 '19 at 20:37
  • there is a similar (but not that specific) thread on reddit about it, take a look, maybe you will find something useful https://www.reddit.com/r/Firebase/comments/bxkhzy/what_happens_with_pricing_if_someone_launched_a/ – andresmijares Jun 06 '19 at 21:04
  • @andresmijares your example is about web site. However this case is about shared mobile application. This means users application directly communicates with Firestore. My concern: If application decompiled with tools, I think they can manipulates all the communication. Because of that maybe they can change anybody's document or they can full my limit with extreme requests. Client side controls is not a solution I have to find some way in Firebase side I think.(Mobile apps is shared package so people don't have to update and they can attack with previous buggy versions or decompile the package) – Gokhan Alp Jun 06 '19 at 21:33
  • yeah that's why i mentioned it's not that specific, not sure what your opinions are about it but for me, it's a 100% architectural design problem, so the problems are similar, I'm curious to see what you find on this end, good luck – andresmijares Jun 06 '19 at 21:38
  • @FrankvanPuffelen Yeah for writes it would be possible, if you wrote a rule that triggered for every single kind of write that needs to be limited, but not for any reads. – Doug Stevenson Jun 06 '19 at 21:57
  • Since this question comes up repeatedly, I just wrote a reference question and answer for it: https://stackoverflow.com/q/56487578 – Frank van Puffelen Jun 07 '19 at 03:27
  • Hi @FrankvanPuffelen I missed something to explain. In my app project I want to do something about sharing data. For example A user will be shared X model document and B user will be read this but B will not be able to write to X. Only A update for X. As B wish to share own document B will be able to write any other documents. I looked your sample, with same way if I put user A user id into X, B will be able to read it so this means B will receive A's id. Is it safe? Do we any way to manage this and share X without include owner id? Note: More than one documents will be available per user. – Gokhan Alp Jun 07 '19 at 08:33

0 Answers0