Hello friends, I’m Jivan, and welcome to my latest write-up focused on Firebase misconfiguration from a security research perspective. In this post, I’ll share my personal approach to identifying and understanding common security missteps in Firebase setups, along with key observations and learning points.
In this writeup, I won’t focus on exploitation techniques instead, the goal is to help you understand how to identify and approach Firebase misconfiguration issues responsibly. By reading this write-up, you’ll gain a clear understanding of:
- What Firebase misconfiguration is
- Why it poses a security risk
- How to assess Firebase databases during your security testing
- Best practices for ethical research and reporting
Whether you’re a beginner in cybersecurity or an experienced bug bounty hunter, I hope this writeup provides valuable insights and helps you learn something new.
What Firebase misconfiguration is?
Firebase misconfiguration refers to a situation where the Firebase database is not properly secured using security rules especially in the Firebase Realtime Database. This misconfiguration can allow unauthorized users (including potential attackers) to access, read, or even modify data. In some cases, the Firebase data may be publicly accessible due to weak or missing security settings.
Many mobile and web applications use Firebase services as a database to store and manage data in real-time. However, if the database security rules are not properly configured for example, if read and write access is left open without authentication then unauthorized users can gain access to the Firebase database and even read from or write to it.
Why Firebase Misconfiguration Poses a Security Risk?
A misconfigured Firebase database can expose sensitive user information or other data that should not be accessible to unauthorized individuals or the public. When security rules are not properly configured, unauthenticated users with access to the Firebase database URL can potentially read from or write to the database.
Here’s why it’s a serious security risk:
- Exposure of Personal Information: Usernames, email addresses, chat messages, phone numbers, and other private data can be publicly accessible.
- Unauthorized Data Modification: If write access is misconfigured, malicious users can tamper with, delete, or insert harmful data into the database.
- Privacy Violations: Public exposure of user data can lead to violations of data protection laws like GDPR or CCPA.
- Reputation Damage: Data leaks can hurt the credibility and trustworthiness of the app or company.
- Further Exploitation: Exposed data can be used in phishing attacks, credential stuffing, or as an entry point for more serious attacks.
How to Assess Firebase Databases During Your Security Testing
Now here’s an important point how to find Firebase database URLs.
In this write-up, I won’t go too deep into the process of discovering Firebase URLs because my main focus is on how to approach Firebase misconfiguration. I’ll cover the detailed methods for identifying Firebase endpoints in a future write-up.
However, to give you a brief idea Firebase URLs are commonly found during Android and iOS application security testing, as many mobile apps use Firebase services. These URLs can often be easily located through code analysis or by inspecting network traffic while the app is running.
Best Practices for Ethical Research and Reporting
When testing for Firebase misconfigurations, it’s crucial to follow ethical guidelines. Blindly performing security tests on a Firebase database can unintentionally lead to serious consequences such as making the database unavailable, deleting critical data, or modifying existing information.
Such actions can directly impact the company, its users, and sometimes even the availability of essential services.
Before testing a Firebase misconfiguration, you should clearly understand what kind of testing you are performing, ensure it’s non-destructive, and stay within legal and responsible boundaries.
These days, I’ve noticed that many new bug bounty hunters rely heavily on automation tools to find Firebase misconfigurations. However, based on my personal experience, I believe that using automation for this purpose is not always effective or safe.
The main issue is that you often don’t know exactly how these tools are testing the Firebase database. While automation might sometimes help identify misconfigurations, it can also lead to serious problems such as unintentionally deleting entire databases or modifying sensitive data.
That’s why I’ve created this write-up to explain how to identify Firebase misconfigurations using a fully manual approach. Once you learn how to test manually, I can confidently say you won’t need automation tools.
Not only will you understand how to find misconfigurations, but you’ll also gain a clear understanding of the impact of each specific test case, which is crucial for ethical and responsible security research.
Practical: How to Manually Test for Firebase Misconfiguration
Now that you understand the theory behind Firebase misconfigurations, it’s time to explore the manual testing process step by step. This section will help you learn how to safely test a Firebase database for open access using simple tools like curl without harming any data.
Disclaimer: Only test Firebase databases that are part of authorized security programs (e.g., bug bounty programs with permission). Never perform unauthorized testing on live apps.
Now, to demonstrate the misconfiguration, I have created a test Firebase database at: https://appsecwriteups-default-rtdb.firebaseio.com/
Let’s begin with the initial testing.
When you find a Firebase Realtime Database URL, your first step is to check whether it’s misconfigured. To do this, simply append /.json to the URL. For example: https://appsecwriteups-default-rtdb.firebaseio.com/.json
When you open this URL in your browser or using a tool like curl, one of the following will happen:
- ✅ If the database is publicly accessible, it will return data (even if it’s empty, it will show
{}null). - ❌ If the database is secured, it will return a message like
"Permission denied".
Refer to the screenshot below to see the response after adding /.json to the Firebase URL
Now, if you see any data being returned by the Firebase database after appending .json to the URL, it means the database is misconfigured and publicly accessible.
Let’s now explore the second scenario, where the Firebase database returns a “Permission denied” response when accessing the URL: https://appsecwriteups-default-rtdb.firebaseio.com/.json
Now, when many bug bounty hunters see the error message "error": "Permission denied", they assume that the Firebase database is fully secured. As a result, they often stop testing and move on to other vulnerabilities.
However, this is a common mistake. Seeing "Permission denied" doesn’t always mean the database is completely secure. In some cases, even with this message, there may still be ways to safely continue security testing based on how the database rules are configured.
In the section below, I’ll demonstrate how to properly approach this type of scenario and what you should check next.
Now, let’s try to access this endpoint using the curl command: curl -X GET https://appsecwriteups-default-rtdb.firebaseio.com/.json Check the attached screenshot to see the output.
If you look at the output of the curl command, you’ll see that the Firebase database is still returning “Permission denied”, which means the database is properly secured for read access. In other words, you cannot access the data from the database.
To assess whether a Firebase database allows unintended write operations, you can methodically test the following HTTP methods: POST, PATCH, PUT, and DELETE. These methods help identify if write permissions are improperly configured.
now lets start with the POST operation so you just need to test the curl command like this
curl -X POST -d '{"Vulnerability":"Firebase Write Access","by":"Jivan Magare (Solo)"}' https://appsecwriteups-default-rtdb.firebaseio.com/.json
This POST request sends data to the root of the Firebase Realtime Database and creates a new child node with the supplied JSON data, if the database is misconfigured to allow write access.
The response will return a unique name (key) generated by Firebase for this new entry. This behavior confirms that the Firebase database is misconfigured and publicly writable. You can refer to the attached screenshot for proof of successful data write.
Now let’s discuss the second method, which is PATCH.
Before running the PATCH request, you need to know the exact existing node in the Firebase database. If the database returns “Permission Denied” on read access, then there’s no possible way to test this method because we don’t know any valid node names.
Please note that this doesn’t mean you can’t test the PATCH method on other endpoints like /.json it can still work. I’m specifically referring to cases where you attempt to modify data at a particular node or endpoint.
However, as we confirmed earlier, the POST method is working, and it returned a node name a unique hash value. Now, using that node name, we can run the following curl command:
curl -X PATCH -d '{"status":"confirmed"}' https://appsecwriteups-default-rtdb.firebaseio.com/-OWQUw2kecuW4Aa5c8ql.json
Now, when this command runs, it adds a new key status with the value confirmed at the specified node endpoint, which already exists in the database. See the attached screenshot.
Now, let’s talk about the PUT method for testing Firebase database misconfiguration.
⚠️ If you don’t fully understand how Firebase works and you’re still relying on automated tools, I strongly recommend you to immediately stop using them for finding Firebase misconfigurations. This is because the PUT method is highly dangerous it can overwrite the entire database at the targeted path. Let’s see what can happen if this command is executed.
curl -X PUT -d '{"report":"Firebase DB open to public","by":"Solo @ appsecwriteups.com"}' https://appsecwriteups-default-rtdb.firebaseio.com/.json
As you know, we are testing this case on a Firebase database. When the database returns “Permission Denied”, we do not have access to see what data is already present.
If you test this case especially using the PUT method without knowing the structure of the Firebase database and rely blindly on automation tools, you could unintentionally cause serious problems.
If an automation tool silently executes a harmful command like PUT, and you later report a bug to the company based on that successful test, it’s highly likely that the company will take action against you.
Why? Because this type of command may accidentally delete the entire database just to show impact. The PUT method, when run on any specific node, will completely replace the entire root of the database.
⚠️ This is extremely dangerous, as it overwrites everything, including any legitimate data previously stored.
Now let’s look at the command output to understand its effect.
When you test using the PUT method on a misconfigured Firebase database, you might see your supplied data added successfully. But be extremely careful this command doesn’t just add data, it actually replaces the entire root database with your input. This is very dangerous, as it will delete all existing data in that node, including legitimate user information. If you are unaware of how Firebase works and rely on automation tools blindly, you risk causing real harm.
Before running such sensitive commands, always ask for permission from the company, and conduct all security testing within ethical boundaries. Avoid using the PUT method unless you’re fully aware of its impact.
This marks the end of this write-up on Firebase misconfiguration and how to properly approach it. However, this topic is much deeper than it may seem at first. One critical method not discussed here is the DELETE method. Just like the PUT method, DELETE can cause severe impact for instance, it can result in the entire database being wiped out if the Firebase rules are misconfigured.
Blindly using automation tools for Firebase misconfiguration detection as well as methods like PUT or DELETE can be extremely dangerous. These actions might overwrite or delete the entire database, especially if it’s misconfigured. It’s important to understand that without proper knowledge or ethical permission, such testing can cause unintended damage. Always make sure you’re performing security testing within ethical boundaries and with the consent of the company.
Through this write-up, you’ve seen how to identify misconfigurations and why even a "Permission Denied" message doesn’t always mean the system is secure. Approaching Firebase responsibly is key to uncovering real security flaws without causing harm.
Firebase Misconfiguration Prevention: A Quick Guide for Developers
To prevent Firebase misconfiguration, always secure your database with proper .read and .write rules avoid using true for public access. Instead, require authentication and apply role-based permissions. Never expose your Firebase config files publicly and regularly review your rules to match app updates. Test rules locally using Firebase Emulator and integrate rule checks into your CI/CD pipeline. Limit services to only those in use and monitor database activity to detect unusual access. Educating your development team on secure Firebase practices is also essential for long-term safety.
🙏 Thanks for reading this case study.
This write-up is meant to share practical insights on how to approach Firebase misconfiguration testing. It highlights why it’s important to:
- Avoid blindly using automation tools for Firebase or HTTP methods like
PUTorDELETE. - Understand what each method does before sending any requests.
- Never test on a company’s system without clear ethical permission.
- Focus on learning the structure and behavior of the target app instead of relying solely on tools.
The goal is to promote a responsible and informed mindset when performing security research. I hope this helps others approach Firebase and other cloud services more carefully and effectively.
Stay curious. Stay responsible. Keep learning.
