How I Hacked the Voting System: A Deep Dive into Firebase and Firestore Security Vulnerabilities

The target? A voting website: https://Voting-App-voting.web.app/. My journey began with the basics — extracting the APK. I started by downloading the voting app straight from the Google Play Store, setting the stage for what was about to unfold

I wanted to check if the mobile version contained any vulnerabilities. To extract the APK, I used APK Extractor on my Samsung phone. Once extracted the voting app, I transferred it to my PC for deeper analysis using APKTool.

apktool d votingAPP.apk -o voting-app-decompiled

While analyzing the decompiled code, I found a partial database name in the resources folder. This was not enough to exploit the system, but it was a crucial lead. That tells me they use default db .To search for default Firebase project

grep -ri "firebaseio.com" voting-app-decompiled/

output
voting-app-decompiled/smali_classes2/S6/d.smali:const-string v4, "-default-rtdb.firebaseio.com"

I then reviewed the requests sent by the app to the backend using Burp Suite, which helped me retrieve the full database name: dbname-id-default-rtdb.

Since the web application was connected to a mobile app,with analyzing the web application’s JavaScript files. While reviewing them, I found an exposed Firebase API key,Full database name ,current project name and id which was a potential security misconfiguration,due to disclosure policy i wont make then public.

Finding an API key in a frontend script is a major security red flag, as it can allow attackers to interact directly with the backend services.

After identifying the database, I tested whether it was publicly accessible. browser.

To my surprise, the entire database was exposed, revealing user information, votes, and nominee details.

I then tested whether I could create a new account with the API key and grant full privileges by making a request to the authentication service. Using the following curl command, I attempted to create a new account with invalid credentials to see if the system would accept the request despite the false data:

In this request, I intentionally used invalid data to see if the system would allow me to create an account without proper validation or reject it as expected. This test helped verify the robustness of the authentication process and how it handled potentially malicious inputs.

boom i successfully register new account with same level as admin ,so i successfully get refresh token and idtoken ill try to make modification like PATCH,DELETE AND ADD

Next, I tested whether I could retrieve a new authentication token using the refresh token. By sending the following curl request, I attempted to exchange the refresh token for a new access token, checking whether the system would grant access or reject the request due to the token’s validity

The goal was to assess the system’s ability to properly handle the refresh token and verify whether any unauthorized or unintended access could be obtained using a potentially expired or invalid token

after obtained an access token i use it to make a full privileges functions

I performed an update operation on a specific document in the Firestore database to manipulate the vote count of a nominee. By using the following curl command, I attempted to modify the votesCount field for the nominee identified by <deducted>. The request was sent with a valid bearer token to ensure proper authorization, which I obtained through earlier testing.

This test was conducted to verify if I could modify data within the Firestore database, and to assess the potential for unauthorized changes to the voting count. The response show successfully change vote of the user .

finally i try use browser to access it public to see if changes made .

i got the same result

A compromised voting system can:

Lead to election fraud by artificially increasing or decreasing votes.Expose personal voter information, leading to privacy concerns.Undermine trust in the voting process, impacting legitimacy.

This type of misconfiguration is one of the most common Firebase security issues, as default Firebase rules often allow open read/write access.

Never hardcode API keys — Use environment variables or backend authentication.Enforce Firebase security rules — Restrict database access to authorized users only.Monitor API traffic — Identify unusual activities through logging and alerts.Analyze JavaScript files — API keys and secrets are often exposed in client-side scripts.Decompile mobile apps for sensitive data exposure — Many apps store credentials in plain text.Test for misconfigured Firebase databases — This remains a common security flaw in many applications.Always follow responsible disclosure — Ethical hacking builds trust and secures the web.

In the end, it wasn’t about the exploit. It was never about the flaw itself. It’s about the power we hold when we look at these systems, break them apart, and rebuild them from scratch — stronger, safer, smarter.

This wasn’t just another vulnerability in the wild. It was a moment where digital security wasn’t just an afterthought, but a responsibility. I reported the issue. The flaw was patched. The system was better for it.

But here’s the thing: there’s always more. There’s always something else to find, something to fix, and someone to protect. And as long as there’s a crack in the system, someone like me will be there, watching, learning, and making sure they don’t get too comfortable.

The system’s flawed, always has been. You want change? Find the cracks. Keep pushing. Don’t stop.