I have rules set up that ensure a foreign key like constraint: when I put data at a certain path, the key is validated to exist at another node.
Rule snippet:
"app": {
"freebies": {
"$provider_id": {
".validate": "newData.parent().parent().parent().child('app').child('providers').child($provider_id).val() != null"
}
}
}
If I run a simulation with these params
Write to /app/freebies
width data: {"totally_fake": 1}
This fails, which is CORRECT.
On the other hand, if I just go to the online editor and add a node to the same location with the same data, it writes the DB without errors.
My question is: does the online editor bypass the security rules ?
Yes, it does. The Firebase console, as well as the Admin SDKs, bypass security rules and have "administrative" access to the Realtime Database.
Related
I'm beginner and I'm developing a chrome extension that shows data received from my firebase realtime database. It does not need Login, or any personal information.
I'm trying to use REST API. Until now I have been in a test mode so I opened access to data for all. But Google keeps mailing me that I have to change the access rule because it is dangerous.
My present access rule is this:
{
"rules": {
".read": true,
".write": false
}
}
Now, I fetch data from https://<project name>.firebaseio.com/<database name>.json. But if I change the rule, the access will be denied.
So I want to add some key to the url and change access rule according to it so that I can fetch data from the url. For example,
https://<project name>.firebaseio.com/<database name>.json?some_key=<some_key>.
I do not need personal keys so I want only one key just like when we get information from open APIs. For example, when I use weather api, I get my api key from the host and adds the key to url.
Is this possible? If it is, I wonder two things.
the key that I can use (for example, realtime base wep API key)
access rule of realtime database
You can't pass parameters to the Firebase database like this:
https://<project name>.firebaseio.com/<database name>.json?some_key=<some_key>
But if you change the order of the values, it suddenly becomes possible:
https://<project name>.firebaseio.com/<some_key>/<database name>.json
We then change the security rules to only allow access when somebody already knows the secret key:
{
"rules": {
".write": false,
"$some_key": {
".read": true
}
}
}
Now the secret key is part of the path of the data, and only a user that already knows the key can read the data for that key.
Data in Firebase has the following structure:
emailsLending
|___-LqQFYK-iI8a8qe2msVk
|___email
|___serverTimestamp
I wrote the following rules checking the entry in the email field:
{
"rules": {
"emailsLending": {
"$emailsLending_id": {
".indexOn": "email",
"email": {
".validate": "newData.isString() && newData.val().matches(/^[A-Z0-9._%+-]+#[A-Z0-9.-]+\\.[A-Z]{2,4}$/i)"
}
}
}
}
}
But when I write data to the email field using the Cloud Function, the rule does not apply and I can write anything, for example, "123".
What am I doing wrong?
Cloud Functions run with administrative privileges, and by default bypass the security rules of your database.
The logic here is that rules are to protect against malicious behavior from untrusted users, while Cloud Functions are authored by the most trusted users: collaborators on your app. To catch mistakes made by these types of users, you'd typically use unit tests instead of security rules.
If you have a case where this logic doesn't apply and you're using the Realtime Database, you can set databaseAuthVariableOverride to the UID of the user to run the code as. For an example of this, see the Firebase documentation on accessing user authentication information.
firebase.database().ref('meetups').push(meetup)
.then((data)=> {
console.log(data)
commit('createMeetup', meetup)
})
.catch((error) => {
console.log(error)
})
I was doing a project made by academind called "project with vuejs vuetify and firebase"
my firebase database rules are:
Access The Firebase Realtime Database is controlled by server-side security rules The error message you're getting matches the security rules that you shared. Those rules say that no ordinary user can read or write any data from or to the database.
The simplest change that you can make to allow the operation you shared is to allow anyone to write a node under /meetups. The rules for that would be:
{
"rules": {
read: false,
"meetups": {
"$meetupId": {
".write": true
}
}
}
}
With these rules, anyone can write a new node under /meetups. But nobody can read any data, nor can anyone write anywhere else (including writing to /meetups itself).
The exact rules you need depend purely on the app that you're building. I recommend:
Reading the documentation for Firebase Database security rules.
Watching this video about security rules in Firebase
Reading my answer here: Firebase email saying my realtime database has insecure rules
Can someone please explain why, while testing Firebase security rules the below two simulated writes which I think are essentially the same give different results?
Write1
Simulator location: /users/id123/state
Simulator data(JSON): {"data":"example}
Write2
Simulator location: /users/id123/
Simulator data(JSON): {"state":{"data":"example}}
Write 1 denies the wright at the "state":, ".write" line in the below rules.
Write 2 skips the "state":, ".write" line altogether.
This is an issue because I am updating multiple paths in one JSON update and its skipping rules.
Does anyone know why?
{
"rules":{
"users":{
"$userId":{
"state":{
".write":false,
".read":false
}
}
}
}
}
Your rule is for denying writes at all the locations at or deeper under your state node.
So any writes at
/Users/uid/state
And any rules under states
/Users/uid/state/foo/bar
Will be denied.
But if you write the data to
/Users/uid
The rule doesn't apply as it's not at or under the state node, it's a shallower node which doesn't have any rules stated. You can put your rules at
{
"rules":{
"users":{
"$userId":{
".write":false,
".read":false
}
}
}
}
The rules above will prevent writes for all the paths under your uid node. Also if you are using the REST api or the admin api, all rules will get bypassed
The REST API and the ADMIN API will both need a service account key file that only you will have. Thus they are secure. They'll give you admin access and will always bypass all security rules at all locations.
In the example you gave you are writing to different locations and firebase security will first look at the location you are writing at to check the rules.
Write2
Simulator location: /users/id123/
Simulator data(JSON): {"state":{"data":"example}}
Here you are writing to /users/id123/ and firebase will check that location for a write rule which in you case isn't present so it will use the default ".write":false.
For writing your rules you have to make sure to set them at the correct level.
Take a look at firebase security authorization (who can read/read) and also validation (what can be written).
I have this DB structure in Firebase:
[bets]
-KTd9VKWJwHd_L6j_oAF
date
team1
etc
-KTdCc7uVmueNtcYzU1m
date
team1
etc
[users]
I'm now trying to write Firebase rules to allow users to only read bets assigned to them. But I ran into problems right away. I have these very basic rules:
{
"rules": {
"bets": {
"$bet": {
".read": true,
".write": true
}
}
}
}
When I try to visit /bets (where I display a list of bets) I get thrown the error:
Error: permission_denied at /bets: Client doesn't have permission to access the desired data.
If I instead place the .read and .write under bets instead of $bet, it works fine. What am I missing?
Firebase evaluates read permission at the location where you attach a listener. You attach a listener to /bets, so it rejects the listener since you don't have read permission on /bets.
If you have read permission to /bets, you also can read everything under it. So this means that you can't use Firebase Database security rules to filter data.
See the section rules are not filters in the Firebase documentation. Or search for Firebase questions mentioning "rules are not filters" here and you'll see this is a common pitfall for developers.