0

I'm trying to query a location db, geofire, but don't want the query fully open from the client's side.

If I allow the Android client to specify the point and radius (as specified here), I'm opening an app for a security breach, making it possible for any user to do whatever query it wants.

One way to prevent that is a server side query (i.e. radius isn't specified by client). But how can I do it with a server-less firebase architecture?

Any other idea to protect the queried data? Thanks.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
AlikElzin-kilaka
  • 34,335
  • 35
  • 194
  • 277

1 Answers1

1

If you want run code in a trusted environment, without spinning up servers, you can look at Cloud Functions or Cloud Run, both of which have integrations from Firebase.

That said, I'd consider what the security risk is that you're guarding against.

The recommended data structure for GeoFire on the Firebase Realtime Database separates the geodata fro the other data of each tracked key in a structure like this:

"_geodata": {
  "sf-muni:1040":{"g":"9q8yyhxbe5","l":[37.773846,-122.420868]},
  "sf-muni:1050":{"g":"9q8zn6egkz","l":[37.807301,-122.415298]},
  "sf-muni:8946": {"g":"9q8ympvrg3","l":[37.705044,-122.468231]},
  ...
},
"sf-muni": {
  "vehicles": {
    "1040": {"dirTag":"F____I_F00","heading":45,"id":1040,"lat":37.773846,"lon":-122.420868,"predictable":true,"routeTag":"F","secsSinceReport":6,"speedKmHr":11,"timestamp":1637368646567,"vtype":"train"},
    "1050": {"heading":75,"id":1050,"lat":37.807301,"lon":-122.415298,"predictable":true,"routeTag":"F","secsSinceReport":3,"speedKmHr":31,"timestamp":1637368659567,"vtype":"train"},
    "8946": {"dirTag":"28___O_F00","heading":88,"id":8946,"lat":37.705044,"lon":-122.468231,"predictable":true,"routeTag":"28","secsSinceReport":2,"speedKmHr":0,"timestamp":1637368660567,"vtype":"bus"}
    ...
  }
}

So the _geodata node only stores an application-defined key for each location, and that is the only data structure that must be readable to all users (as you can't query data that you can't read). To look up the actual data for each key requires an extra lookup in this data model, which can then have its own security rules.

Only if you use data events (which I recommend against), are you joining the two types of data and thus end up with a single set of security rules for both of them.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks Frank. Upvoted. But I still don't understand how to protect the data. Even if I extract just the keys, from the geo data, the user has the keys and can query using them. How do I provide the query params from FB "server" and not from the client? (without a dedicated server). – AlikElzin-kilaka Feb 26 '22 at 07:50
  • To add to that, I couldn't find any option for fb side query params in security rules. – AlikElzin-kilaka Feb 26 '22 at 08:03
  • It all depends on what the data access requirements are, which you don't specify. If someone "has the keys" in their code so that they can call your server, they can also take those keys and run their own code against your server. Firebase's configuration data is no different in this sense (longer explanation here: https://stackoverflow.com/q/37482366). I recommend thinking about the data and its access patterns, and defining the rules for allowed access. For example, if a user can only access data from folks in their friends list, that is something that can be done in security rules. – Frank van Puffelen Feb 26 '22 at 15:45
  • Thanks. Can we define geo-location security rules? – AlikElzin-kilaka Feb 26 '22 at 16:41
  • You can write security rules for any node in your database. Start by defining what data the user must be able to access/query, keeping in mind that you can only query data that you can read (as [rules are not filters](https://firebase.google.com/docs/database/security/core-syntax#rules-not-filters)). Given that a geoquery filters ranges of the `g` property, you could define [query based rules](https://firebase.google.com/docs/database/security/rules-conditions#query-based_rules) on that. But again: define what you are trying to protect against, and only then translate that into security rules. – Frank van Puffelen Feb 26 '22 at 16:56