How was Google Firebase security bypassed?

Appthority Inc. discovered thousands of mobile apps were leaking data from insecure Google Firebase databases. According to the vendor's research team, these cloud databases do not secure data by default, and the app developers didn't configure the settings to protect the data. Should Google have default security settings for Firebase or are the developers more to blame for not configuring their Firebase instances correctly?

Most software applications use a back-end database to store information like user credentials, logs and data used by the application, and those that live on the internet often use a cloud-based database to ensure scalability and high availability. The main options include Amazon Relational Database Service, Oracle Database Cloud Service and Microsoft Azure.

For developers concentrating on mobile apps, there is also the option of using Google Firebase, a mobile and web application development platform that provides a real-time database that continuously syncs data between the cloud and the users' mobile devices. The competition between these services to attract developers and their projects is intense, with marketing material promoting how quick and easy a particular service is to use.

While researching insecure back-end servers connecting to mobile apps, the Appthority Mobile Threat Team (MTT) found that Google Firebase was one of the 10 most popular data stores for mobile apps in 2017. They also discovered that Firebase databases are accessible via an API and that if developers haven't correctly secured their Firebase database, a simple web request can retrieve its entire contents.

MTT tested this attack vector on over 2.7 million iOS and Android apps and found over 113 GB of data was exposed through 3,000 apps, including at least 4 million records with protected health information; 25 million GPS location records; 50,000 financial records; and at least 4.5 million Facebook, LinkedIn, Google Firebase and corporate data store user tokens, with health and fitness apps leaking the most data.

MTT has named this type of vulnerability, in which data is exposed not by flaws in an application's code but by the development team's failure to properly secure the back end, HospitalGown. The reason that it's so prevalent among apps using Google Firebase is that there is no database security turned on by default.

While most applications tend to have security and privacy settings turned on by default, a development platform can be difficult to learn and awkward to use if the security settings are turned on at the beginning of the development cycle, slowing down the initial development phases while the code and functionality are being tested. Anything that slows down development is likely to put developers off using a particular platform.

As a default Firebase database has no security, it's the development team's responsibility to correctly secure the database prior to it storing real data. In Google Firebase, this is done by requiring authentication and implementing rule-based authorization for each database table. The configuration and security controls for any sensitive data also need to be checked using vulnerability scanners and pen test tools to verify that they have been implemented effectively. Clearly, there are plenty of projects that fail to implement these critical stages before releasing their applications.

While the fault lies with developers and their lack of awareness about secure coding practices, the fact that so many apps connect to unsecured Firebase databases suggests that the Firebase documentation is not clear enough about the dangers of not securing the back-end infrastructure.

However, some of the records stolen included 2.6 million plaintext passwords and user IDs. Even those that may argue that Firebase should be more secure by default cannot disagree that not encrypting passwords is gross negligence on the part of the developers responsible.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)