Thunkable Documentation s̶u̶g̶g̶e̶s̶t̶s̶ ̶u̶n̶s̶a̶f̶e̶ ̶D̶a̶t̶a̶b̶a̶s̶e̶ ̶R̶u̶l̶e̶s̶ ̶f̶o̶r̶ ̶F̶i̶r̶e̶b̶a̶s̶e̶?̶ is correct!

Hi,

The current “recommended” rules for Firebase are:

{
 "rules": {
 ".read": true,
 ".write": true
 }
}

Here is the demo structure I created in Firebase:

The problem with this is, when using Postman for example, I can see all the information in the Database without authentication, for example:

https://demoproj-1-92962.firebaseio.com/top-level.json

Will return all the information in the top level with no authentication

This is a HUGE security and privacy issue, because Thunkable is essentially telling users to open up their data to the world. With client data, or even accounting information present in the Realtime Database, leaving it totally unsecured is not even remotely an option…
:-1:

But, when you add secure Rules to the Firebase DB, the API key from the Firebase project settings no longer works.
For example:

//only authenticated users can access/write data     
{
   "rules": {
   ".read": "auth != null",
   ".write": "auth != null"
   }
}

As this is a low-code / no-code platform, one would expect Thunkable to create even a basic level of Database security documentation for it’s users. At the moment, anyone using Thunkable with their Realtime Database Rules set to:

".read": true,
".write": true

Can have their entire database read by anyone who knows the data structure :astonished:

So, Thunkable, is there a solution!?
:face_with_raised_eyebrow:

Yes there is.

@eoinparkinson has posted about how to fix Firebase rules as have others. Their docs tell you how to do it.

Check out my twitter @jaredgibb3 and vote on my next tutorial. I can cover this topic but need motivation!

2 Likes

As mentioned, the ‘docs’ are the problem.

Thanks for the fast reply though.

Thanks for the feedback @appspark.uk, we take security matters very seriously and will make sure that this is updated appropriately.

3 Likes

That’s great to hear @domhnallohanlon, appreciate your time on this, thank you.

Hey @appspark.uk,

Did you get this to work for you eventually? Basic Firebase security rules work fine when storing all user data under their UUID. Thunkable has Firebase auth built in to the client side app, so Firebase rules should work for you.

If you’re trying to set up user specific data, and then secure it, you will need to integrate authentication.

For a short intro to Firebase rules, I highly recommend watching this video.

2 Likes

I’m aware of the Firebase User Auth (module). I don’t need User sign-in, just the normal API Key.

If you take another look at the OP, it shows where there is an issue, it is not to do with User Auth. but the API Key not working when adding Rules to the Database.

What I’m looking for, are Rules for Firebase that allow the API Key to work, but don’t leave the database API open. So far I haven’t found anything that doesn’t require User Auth.

Here’s an example of some Firebase rules, none of which work for this scenario.

Hi @appspark.uk,

You will need to be a little more specific. An API Key is required for you to be able to communicate with the Database correctly. Do you want public read access but deny write access?

Can you provide a detailed example of what you expect to happen?

Thanks

1 Like

@eoinparkinson

Hi, this statement is incorrect. If you see the Postman image in the OP, I do not use an API key or Auth of any kind. But can still access the Firebase data.

I’ve enabled the demo database with the Rules from the Thunkable Docs.

If you use Postman (or other) to access it, you will be able to GET the data. No Auth.
https://demoproj-1-92962.firebaseio.com/top-level.json

The data is open to the world :open_mouth:

To clarify, please see this new screenshot:

.
How can I be sure there is no Auth? I have not added any Body or Parameters. These are the generated headers:

demo-firebase-project-postman-generated-headers

As you can see, the data is available to anyone, if they know even a little bit about the database. Thus, anyone using Firebase in their app (without Firebase Auth), has completely unsecured data

:confused:

To show how this is affecting Projects:
(ignore my custom CSS ‘dark’ theme)

As you can see, even without the API key, the app still gets the data.
.
.
If you’d like to test, the Project is here:
https://x.thunkable.com/copy/d5eeb1c217115d0645266a0e11822ea2

Well when you don’t use an api key, the system defaults to thunkables api key

https://docs.thunkable.com/realtime-db

1 Like

Yes this is what will happen, so you must secure your database. There’s no other way about it.

Add rules to your database to secure it from attackers.

@jared
This is not an answer, in fact it’s intentionally misleading. I was not using the default account. It doesn’t say that anywhere in my OP. Please read my (legitimate) concerns carefully, before you give a (sassy) reply.

I have previously shown what happens when adding rules… If you see my example, it is easy to access the data without authentication. Adding authentication blocks all access from the API key.
To clarify, the Firebase Rules suggested in the Thunkable Docs seem to block all access.

Has anyone at Thunkable actually tried this?

I am deeply concerned that Thunkable is not taking this seriously. Firebase Rules need to be added, but all the Rules I have tried so far require OAuth or something else, and the API key is denied access.

I am not an expert in this, by any means. But please, Thunkable, come up with an actual solution, because at the moment all your customers are leaving their data open to anyone to just copy it all (if they follow the instructions on the docs).

There are more than likely some apps storing; sensitive data, HR data, patient data, and, or financial data.

It is clear that is up to Thunkable to provide its’ customers with a solution, that bridges this gap, or should I say, this chasm, between Firebase and the Thunkable platform, to ensure even a basic level of data security.

@appspark.uk I’m finding it really hard to understand exactly what you’re not satisfied with, and that bit is on me. However fwiw, I’ve got a Firebase database set up and have ran numerous tests to check if my rules work as should, which they do. Only the authorised user can access their data. I can check this because trying to retrieve data that is not mines does not work, and Firebase logs a “deny” on the stats dashboard. Security rules are usually server side and not client.

Since you are using an external service (postman) to test your database (Firebase), I don’t understand how this is Thunkable’s problem. As the docs suggest, keeping the database fully public is good for testing purposes. Database rules are not the first thing you look at when building your application. I’d suggest getting your app to work with no security, and then once everything works begin to build your rules.

1 Like

Dear Thunkable team,

I was wrong, I admit that. I don’t know what was going wrong, perhaps some cached data.

Please delete this post, it is incorrect.

1 Like