Understanding Row Ownership vs front end restrictions

[Ruak]

Context : It is clear the front end level filtering of buttons/views is all client side and if data is being downloaded on the user’s device then everything in the front end UI/UX can be bypassed via browser inspection tools like dev tools etc

Scenario:-
Lets say we have a private app for a company with signed in users on the basis of OTP login via e-mail. E-mails are added in the user tables along with their info by default so only authorised users can sign up and row ownership is on the basis of e-mail. There is also a role column with admin and users and data table is made so that admin can view all user columns while users own just their rows. Once a user signs in then they own their row in the users table. Now lets say i want them to see their data - name, e-mail, Role, contact, address, photo, gender etc.
BUT :-

1. I DONT WANT THEM(Users) TO BE ABLE TO EDIT/DELETE THEIR OWN DATA
2. I DONT WANT THEM(Users) TO BE ABLE TO INSERT NEW DATA ROWS
3. Only Admin has rights to points 1&2

Questions :-
Q1) Does row ownership give the complete access to a user for that table such that they can read,write,edit,delete their own rows & they can even add new rows(even when we have actions/front end settings set that they can’t edit/delete/add), from client side browser dev tools or does glide somehow prevent that server side somehow ?

Q2) Can we create true backend security where we can selectively give permissions for reading, writing, editing and deleting selectively to the user i.e. just read and edit or just read, etc. ?

Q3) If Row ownership is really, an either have it all or none, in terms of access to data rows, then are we just assuming that there will never be a malicious user capable enough to reach beyond front end filters that are preventing him from editing/deleting things he shouldn’t because owning your data doesn’t always translate to being able to delete/modify it whenever you wish.

I have given the user table examples but there are so many examples where this would apply viz. Sales agents can see their monthly targets but can’t edit/delete those, sales agents can enter their sales values against monthly sales but can’t edit/delete those, user can see a products table and add new products but can’t delete the added product - In all these cases the user will get access to their rows in the respective tables but getting full control is not secure at all and securing it via front end restrictions like filtered buttons/visibility conditions is not true security.
I hope i am wrong and missing out something.

@NoCodeAndy @Darren_Murphy Need your expertise here please!

[Robert_Petitto]

Regardless of Rows and Row Owner permissions, CRUD actions are allowed if the frontend allows it. To my knowledge, there are no backend permissions for CRUD actions. Frontend devs need to be vigilant not to include a button that allows unauthorized users to create, edit or delete data.

If I’m missing something, I’d be happy to proven wrong.

[Ruak]

Its quite literally the opposite of what you think. True Security in software dev is based on “Server side security”.
Front is only for UI/UX.
A button/widget made or not made doesn’t make a difference if the underlying backend allows the changes. Glide’s documentation is very clear on this.

[Robert_Petitto]

I don’t disagree with you, I’m just speaking from 8 years of Glide Experience. Glide does not have a mechanism to prevent CRUD actions based solely on backend permissions (row owners).

[Ruak]

Exactly what i was saying. But the thing is that depending on front end filtering for CRUD restrictions is expecting a user to act in good faith and never try to by pass those. Like “not having a delete button visible to the user” doesn’t secure the data from deletion. If a determined user wishes to delete then they can delete(via front end inspection tools) and if this is a glide limitation then that’s what i wanted to confirm so i know what to build and what not to!

[Code_X]

How you gonna delete anything via dev tools??? the only data stored on the client device, are USC columns and fetched data from the server that you can’t accessed from there, so you only can manipulate user data and html, but it will not sync back to the server, or maybe you talking about making delete button visible by inspecting element? If is not injected by script.

[Code_X]

I just tested you theory and is impossible to change value through inspect element, and elements are injected by script, so you don’t have them in HTML if they are hidden.

[Jeff_Hager]

I can’t speak on behalf of Glide, but I’ve been working on a project outside of Glide with a heavy priority on security, including which databases, tables, and even which individual columns in my tables are accessible to each application. Even then, I’m locking down to individual read, insert, update, delete permissions per table or database. Of course, I’m handling all of that server side, so even if someone directly hits my api endpoints, there are several authority gates to pass through server side before it will even respond. That includes a three tiered user or application authority, depending on if the user is authenticated in the application, or just a public user, and if the application or user has management authority.

That said, all of my API calls and data access are authorized to only the calling applications that I permit, and that application authorization check happens server side, so even if I tried to bypass the application and call the API directly, it would fail immediately. I would have to think glide works the same way. Endpoints would have to be derived directly from the application authorized to call them. Assuming you can’t interject the API mid call from the approved application, I think you would be safe as long as you can’t expose front end controls, which are react based and can’t easily be manipulated. (Your question does bring up a point of something I should verify in my project, but I think I know what the answer might be.)

Again, I can’t speak on Glide’s behalf, but based on my experience, data manipulation is probably more locked down than you think. Seeing the data that has been downloaded to the device is one thing, but calling API endpoints is a different story. Even if you can find the call itself through inspection, you still have to contend with CORS as well. Considering that glide has passed Pen tests and SOC 2 audits up to this point and those people doing the tests and audits know a heck of a lot more about security than most of the rest of us do, I think the security odds are in your favor but it would be nice to have confirmation from glide on this.

Edit: After doing some more reading I think it might be possible to interject and manipulate the API call. This is just speaking generally and not specific to Glide. The only way to prevent malicious behavior would be to add server side gates at a table, user, or even column level. That’s getting pretty granular and leans into being a nightmare at the maintenance level. Based on what I’m reading, it almost appears to be the reality of the web that is hard to avoid. Starting with no-trust security at the server level, and then opening up a series of security checks to determine what is allowed through. Since Glide does not offer such granular control other that row owners, it may come down to trusting your users. The general thought is probably more focused on preventing unauthorized data access as compared to what you can do with the data once you have it.

Security management is hard.

[Ruak]

@Jeff_Hager Your Edit is exactly where I landed too. Two things worth pulling apart:

Your initial point about app-authorization and CORS is true — but only against someone hitting the API from outside the app (Postman, a separate script with no session or origin). It doesn’t help against manipulation from inside the authenticated app, because there the request genuinely originates from the approved origin with a valid session, so CORS waves it straight through.

On SOC 2 and pen tests — those certify Glide’s infrastructure against unauthorized access, which is a different threat from “an authorized user manipulating data already within their row-owner scope.”
So we agree — Row Owners is the only server-side gate, there’s no granular per-table/column/operation control, and absent that it comes down to trusting your users or moving authority server-side, which is exactly the per-CRUD gating you’re building outside Glide. That’s the confirmation I was after.

P.S. - I am new to the world of full stack development and i’m keen on learning the best coding practises so i converse a lot with A.I. to understand common pitfalls related to security/scalability etc. So when i noticed something about glide i wanted to know if was thinking in the right direction or not. I know what i’m saying is like applicable for 0.01% of the userbase but i this is more of me learning the limitations of code and platforms so i know what to build where. I’m a big time glide fan btw!

[Ruak]

You’re right about what you tested — it’s just the wrong layer. Editing values via inspect-element and trying to un-hide components won’t do anything. But that was never the vector. When you legitimately edit a field, the change doesn’t travel to the server through the DOM — the client fires a network request (a set-columns-in-row / delete-row / add-row-to-table mutation) carrying your session. That request is the write path. The real question is whether a determined user can issue that request — or intercept and alter the one the app is already sending — for an operation the UI never gave them a button for.
How you’d actually do it, and how hard it is. Nobody reverse-engineers authentication from scratch — the method is capture-and-replay:

1. Open the app while logged in, open dev tools → Network tab.
2. Do something the app does allow — edit one field. Watch the mutation request appear.
3. Right-click it → “Copy as fetch” (or cURL). You now have the exact request with the live session credentials already attached.
4. Paste it into the console, change the JSON — a different column, a different value, delete-row instead of set-columns, a rowID the UI never gave you a button for — and run it.

That’s the whole trick. The session authenticates for you because you’re acting from inside the already-signed-in browser. The only friction is that Glide’s internal column names are tokens, not the friendly labels — but those tokens are sitting in the JSON the app already downloaded, so it’s a five-minute scavenger hunt, not a wall.

P.S. - I’ve been working with A.I. to figure this out as part of learning good coding practises. You can do too.

[Code_X]

You’re assuming the captured request can be modified without invalidating whatever authorization controls the backend applies. That’s the part that hasn’t been demonstrated.

Yes, authenticated apps typically send mutations through network requests rather than the DOM. And yes, a user can inspect those requests. But being able to see or replay a request is not the same as being able to perform unauthorized actions with it.

If Glide includes request-specific authorization, server-side permission checks, operation allowlists, row-level access controls, signatures, nonces, or other integrity validation, then changing set-columns-in-row to delete-row, targeting a different row, or modifying protected columns may simply be rejected by the server.

The real test isn’t whether you can copy a request from DevTools. The real test is whether the backend accepts a modified request that exceeds the permissions granted to that user. Until that’s demonstrated, this remains a theoretical attack path, not evidence of an actual vulnerability.

In other words: authentication gets the request to the server; authorization determines whether the server executes it.
Did you tried to hack it?