This depends on what your definition of "safe" is.
Speaking strictly as an engineer, my definition of a "safe" application is fairly straightforward:
- Does not expose sensitive information (e.g. credentials, personal information from use of the application) to unauthorized individuals
- Cannot be leveraged as a "point of entry" for other attacks on other servers, either in my control or not
- Does not expose sensitive business logic or otherwise proprietary operations based on data stored within it
I omit the "snatch-and-grab" scenario described for an employee internal to your organization who takes data from your system and distributes it, since that is a legal and policy matter more than a technological matter. From a technical standpoint, the major things you can do in this scenario is ensure that the access they have to those systems is revoked and that the credentials used for the app are rotated.
As with most things "online security", it boils down to a level of assumed trust. A properly configured Firebase app will likely guard against unauthorized third-party actors from accessing your data, resist third-party actors from compromising the server in which it's on (it has to be on someone's server somewhere), and it likely won't be eligible as a stepping stone for others to attack other servers.
The issue then arises with the trust of whomever's hosting the Firebase servers. Are they trustworthy and do they have a good track record of maintaining data integrity? What policies do they have in place for a rogue or disgruntled employee either damaging the data (effective DoS) or leaking the data? Where's that drawn up in the SLA we have with them if we have to take them to court over it?
I've toyed with the idea of using Firebase for a few pet projects, but I've never really committed to using it for anything major until I can at least get the legal questions answered. The data I deal with is sensitive enough that one could face jail time for improper handling of it, so we have to be very cognizant of who's handling our data and what the SLAs are for it.