Penetration Testing Firebase Web Applications


Hello All. This is my first blog post with the new domain 😀 This post is all about how I was able to takeover the entire firebase database (Firestore) and could perform all the actions an attacker should not. Most of the articles about firebase on security is more inclined towards mobile applications, however, there are no such posts regarding firebase web. I got a chance to perform pentesting in one of the client’s web application and thought to share it with you all.

Sometime back, the team was working on an engagement with a firebase as the tech stack. Web, DB, analytics, and crash reports, were managed on firebase itself.


They could not intercept the target web application with proxy and were facing issues. I stepped in and tried analysing the application. Here, as the entire application was managed by google, it was near impossible to find the technical problems, however, it is possible to discover misconfiguration and privilege-based issues.

There were no privilege-based issues as we only had a single-user role but we could have horizontal issues.

As a prerequisite, I asked for read access over the firebase console to see what is going on at the back.

Most of the articles are mostly mobile pentesting oriented while talking about firebase, but, we were facing a web as a target here.

/.json for firebase and was an error. However, a successful attack looks like this:


If there is an error, meaning, it is fixed already or it doesn’t exist.

{ "error" : "Permission denied" }

The Hit:

Next, I tried to find anything sensitive in js. While doing so, I found interesting strings as shown in the below image.

API Keys

Yes, I found API keys in a javascript file. These are the firebase API key and critical endpoints.

I used this amazing tool firepwn created by @0x_shaq. I quickly configured the tool locally and was able to register as a user on the firebase console as can be seen below. There was no such registration functionality in the application.

Here are a few more pieces of evidence on the successful attack:

Write a new collection
Read Existing Collection

Apart from these issues, we were able to find the following vulnerabilities in the application:

  • Insecure Direct Object Referencing
  • Forced Browsing
  • Data Exposure
  • Header Injection
  • XSS (It worked!!)
  • Session-based issues
  • Local Storage issues
  • Rate limiting, etc.