Edit Security Question

Ask for Help
1

Hi team, I have a question about Glide’s security around data edits.

I have a table that should be viewed by all users, and rows in that table are created by users. For allowing users to edit rows, I’ve already set up visibility settings for editing rows around “does user email match row creator email”.

My concern is this: As glide downloads the full sheet, I worry that a bad actor could potentially change a row that they do not own, through inspect element or other circumvention of the visibility of the edit elements.

Having rows that are visible to all users but editable by only some users, and ensuring that data is secure and cannot be compromised is a key requirement of my app.

Is this something that Glide supports or should I look at another solution for this type of security? Can view, cannot edit.

1 Like
2

Just to be clear, inspecting elements on a public table does not mean it’s possible to change the source data. Only you and people who have access to the underlying Sheet/Glide Table can do that.

You are structuring the right condition for the editing part, so I don’t think there’s something to be worried about here.

The editing element is only generated by Glide when conditions are matched. As far as I aware, adding things in the source code does not grant the ability to mimic that button.

3

Awesome, thanks. So to confirm, does Glide perform any sort of back-end authentication when receiving an edit request? I.e. someone can’t spoof an edit request and the server will consume it?

I want to make sure that only users that created rows can edit those rows, but as for presentation that’s less of a concern, as all rows should be public anyways.

4

I can’t say for sure about that back-end authentication, but on the front-end only users you allow to edit can edit anyway.

5

That’s good enough for me for now. Thanks for the help!

1 Like
6

Glide has a bunch of security checks on the backend.

Most importantly, it will never allow editing a row in a table that has row owners, where the row is not owned by the logged-in user.

2 Likes
7

I would like to pick up the topic again.

As mentioned in the Security Center documentation of Glide: The visibility conditions are just so the end-user does not see specific elements. Like not “see” an edit button → not stop the underlying network requests which can be manipulated by any one with coding/network understanding.

@ThinhDinh
The editing element is only generated by Glide when conditions are matched. As far as I aware, adding things in the source code does not grant the ability to mimic that button.

A potential bad actor does not need to look or change the source-code, they look at the network requests and can manipulate a request to tell the server to store potentially any element or data.

@Mark
Most importantly, it will never allow editing a row in a table that has row owners, where the row is not owned by the logged-in user.

Although, this is true for a column with a ‘Row Owner’, the use case which the topic owner describes is different: All can see, only specific users can edit

Does not allow the use of a Row Owner, as this would prevent every user to see all data.

@Mark
Glide has a bunch of security checks on the backend.

When inspecting the network traffic of an edit request (when the user clicks save/ready), the browser directly sends data to the Google Firestore API, which is NOT the Glide server, it’s directly connecting to the database.

It is possible to set up security rules within a Google Firestore database, the question would just be if these are automatically set when we create a “condition” in the Glide interface for the Edit/Add buttons?

Then there is still the “Visibility is not a security feature” dialog warning which pops up as soon as you try to add a condition for edit/add-form the Gilde interface

There are still lots of unknowns and I would appreciate a clear answer from the Glide team as this is security-relevant!

Thank you :pray: