App Security Questions


I’m working on a health app where users would enter some of the blood work information. It is designed only to by used by the individual, and not digitally shared with medical professionals or institutions (trying to keep it away from HIPAA purview). I’ve enabled Row Owners so that the user-entered data cannot be seen by others.

However, is there any way to encrypt data that is entered by the user so nobody (not even the app developer) can see it? Somehow this doesn’t seem possible to me, but I thought I’d ask, especially if anyone has worked on apps with sensitive information.

Any other feedback on levels of security and protection of data using Glide app would be greatly appreciated.

Thanks so much.

Jim Spellos

Have you looked into protected columns? I recall the feature was released a long time ago.

I’ve never used the feature, I never managed to wrap my head around it. I believe the data cannot be viewed by the Glide developer and isn’t downloaded to devices, however, the data can be read by Glide.


Key phase here is that data isn’t downloaded to the device…meaning that it can’t be used by the app. And really, there isn’t anything preventing the developer from turning off the protection and viewing the data. I think it’s more useful in cases where you have an existing table with columns that should not be used by an app, for example, like in the U.S. where we should never share an SSN or Tax ID. If you happen to have an existing table of data that contains a tax id, but is not needed by the app, you can make it a protected column, so glide completely ignores it and it’s contents. So for those reasons, protected columns wouldn’t work in this case.

As far as encrypting data, I don’t think there is a good way to do that with glide. I think the data is encrypted during transmission, but while on the device, it must remain unencrypted to be read by the app.

Glide really isn’t designed to hold data that is not viewable in some way by the developer. The best you could do is use a bunch of user specific columns, which would get you closer, but it doesn’t stop the developer from viewing the app as anybody else to view that user specific data. The only safe solution would be if a copy of the database could be stored locally on each user’s device, but that’s not the case with glide. Just knowing what I know about how glide works, I don’t see any way that user data could be stored in a way where it’s not visible to someone with access to develop the app. That’s where it’s useful to make sure the developers are trustworthy and/or they have signed an NDA, or make sure the types of data fit within Glide’s Terms and Privacy policies.


Just one thing I want to point out about Protected Columns.

Although the data in protected columns can’t be seen (except as pointed out by Jeff) and isn’t downloaded to users devices, they CAN be written to via an Add Form.

1 Like

The time has come for me to start understanding protected columns then.

I understand Jeff’s explanation: data in protected columns isn’t downloaded to devices, it cannot be read. Indeed this makes sense for particularly sensitive data that might have existed in the table/sheet and should never be used nor read: social security numbers, bank information, health information, etc.

The following pointed out by Darren is what I don’t understand about protected columns as explained in Glide Learn: “However protected columns can be written to – so if you’re using a Form or an Add screen – user will be able to submit data to that column – but once it’s been added, it will no longer be accessible.”

So a user could submit sensitive data, it would seem natural within the flow of the experience to do so (that’s why they would submit the data in the first place), and at the same time, the developer of the app would consider the data off limits and never use it? This I do not understand. What would be a use case?


I can’t think of any specific use cases, and it’s probably not a very useful feature when you only use glide tables. But, if you have data in google, excel, or airtable, then I can see cases where your may already have data, or you may want to aquire data that you need for your own internal company uses. Maybe you want to gather sensitive information using a glide app, but you don’t want to display or use it in a glide app. I’m sure some of Glide’s customers had a need for it, and that’s why it’s there.

It’s not about protecting the data from the developer or the company. A company may have internal needs for that protected data. The developer has full access to the data regardless. It’s more about protecting data from other users. Imagine a public table that cannot use row owners. All users need to see all rows of data in this table, but the table also contains some sensitive information in specific columns that isn’t necessary for the app, and isn’t necessary for the user to see. In that case, you protect the columns with the sensitive information. It’s probably not a common scenario, but Protected columns are there if and when you need them.


Aha. Collecting data via Glide that will then be used in Google Sheets or Airtable makes a lot of sense actually. I wonder if the data in a protected column in a Glide Table could be used via Zapier/API (sending the data out basically).

1 Like

Thanks to you all for the informative and useful feedback on security and Protected columns. Your feedback is greatly appreciated, and helps me (and us all) learn to use Glide better and better.



Good question. I haven’t tried it myself, but I have doubts that it would work. I’d be curious if anybody has every tried.