I found out a security problem on Softr (thanks to Benoît de Montecler from nocodenohack.com (Bubble Security Plugin creator)).
I discovered that it is very easy for a user or a visitor of a Softr website to have a full vision of the Airtable basis behind the data shared on Softr. I mean if you have an Airtable base with Table 1, Table 2 and Table 3, even if you show only one data from Table 1, everyone can see the full data of the three tables.
I loved Softr but I had to stop my project on Softr and try to find another tool…
The Softr team, could you please solve this security problem ?
I know a lot of people stopping their projects on Softr because of that issue. I think you lose a lot of clients because of this problem.
Is there a resource that we can use to test if our data is visible? How do we mark fields/tables as readable?
This is very concerning, I should say…I don’t fully understand how this would be visible and the comment is not 100% reassuring. This is a big deal if that’s not already clear. Please let us know how this will be corrected and step-by-step details of a workaround to ensure data is not visible that shouldn’t be.
There is no resource to test, I will try my best to explain
Let’s say your base has three tables: TableA, TableB and TableC.
If your webapp is using TableA in a way that non logged in users (all users) can see the TableA content, then it says it. Non logged in users (all users) can read/see Table A content. Here is an example: Job opportunities at Softr we have our Jobs table open to all. Within the same base we have other tables which users can not read/see.
If your webapp is using TableB in a way that only logged in users can read/see the content then only logged in users can see the content.
If your webapp is not using TableC then no one can read/see the content.
Saw a webinar from with Benoit not long ago. Made me a bit worried about how much our data could be exposed in Softr apps too. As I remember, one of the first things advised for Bubble apps, was to implement role-based permissions. This is a similar too what Artur is describing.
Another one was that pre-defined field values (e.g. single select, multiple select) we’re easily exposed, while unique value fields (e.g. text fields) better protected. But don’t remember how this one worked precisely.
Since Benoit could built a whole webapp around better securing peoples Bubble-app, there must be more we can do and take into account to minimize our data exposure.
Would love some webinars/resources/checklists/documentation around best-practices and considerations for data-security in Softr apps… !
I view this as an ongoing security/privacy issue. window.logged_in_user contains the entire user record, including fields that we may not want a user to see (indeed softr-airtable-record-editor.min.js contains a function AirtableRecordEditor() that dumps it all out via console.log()).
Is there any reason why the Softr backend could not limit the fields that are baked into the frontend JS code, by looking at (1) the Item Fields/List Detail Fields/etc that the user selects when configuring their blocks, and (2) the fields selected within Edit Permissions? This seems to be what Stacker does.
@Gary we will be working on enabling some granular configuration what can be exposed via API. In few weeks we will have it released. For now if you have a data that owning user should not see put into linked record. Generally it’s a good practice to expose user record in app state or via api so that people who want to write custom code can work with it.
