Data security - Read Only

I must have missed something?

Q. If a user has privileges to View (Read) the particular field they can also Write to it?
There is no Read Only option and View actually means RW?

John

Hi there, @jgellis… if you are talking about the View all fields checkbox in privacy rules (or unchecking that box and checking the boxes associated with certain fields), yes, view means users can see the fields, which means they can read and write (assuming you have workflows in place that allow them to make changes to the fields) unless you have implemented some sort of role-based security that limits write access.

Best…
Mike

My understanding is that to create/modify data you need to have created a workflow for that purpose. To implement security on that workflow, put a condition on it related to the user. Bubble’s manual discusses this in the same section where it talks about privacy roles.

Mike et al,

Ok so if I understand this correctly - write prevention on fields that the user has VIEW on is accomplished solely via the workflow constructs?

John

As ed mentioned, yup.

OK, if that is the case what is to stop a person from capturing the client-side session variables containing the current session id and or user authentication then doing a POST call to the API endpoint to write to a field - where only a read workflow exists?

1 Like

You want my honest answer to that? (You probably don’t, but what the heck, I’ll give it anyway.) I’m a true no-coder, so I just assume a platform with founders as badass as Josh and Emmanuel, a hundred mil in the bank, and over 2 million users has figured stuff like that out. If they haven’t, then I guess we’re all screwed.

That being said, you obviously needed someone way smarter than me to respond to your post, so I will shut up now and let those folks give a real answer.

2 Likes

Hi Mike, I agree with you that there likely is a good answer to this. I do disagree that there needs to be someone smarter than you. It is not a matter of smartness - just a matter of knowledge. You are obviously very smart.

My natural curiosity leads me to ask the question for understanding. If I don’t understand something I like to dig until I do. One would think that Bubble would be able to readily answer this question? I would be surprised if they did not have a Chief Security Officer or similar security position given the broad user base.

I’m not suggesting in any way that Bubble’s security model is not robust. Rather, just that it is a mystery to me at this point. I would enjoy very much being schooled on this by a pro!

1 Like

You can always reach out to Bubble support. Might be worth checking with Bubble directly as almost all here on the forum are just helpful people/bubble users.

support@bubble.io

1 Like

Speaking from someone who has probably spent way to much time looking into the visible inner workings of the Bubble framework (e.g. dynamic.js, run_debug.js, doapicallfromserver, mget, msearch, bubble.io/api, node reflect, etc) I can tell you that your data is pretty well secured if you use the security constructs provided. I’m defintely not a CSO, however I would say if you are really curious start digging and let me know how deep the habit hole goes. I’ve been down it pretty far and only found a few “interesting” bits, none of which give me concerns about data security specifically.

Thank you to everyone responding… just in case there is group curiosity I have sent the following request to Bubble support, and will keep this thread updated if I gleen any insights that may be of intrest.
John

Hello,

Would it be possible if you could provide the Security Architecture documentation, unless of course it is proprietary.

I have read the online user documentation provided and do understand the description of the implementation of the security approach both at the DB and UI-workflow level. However; it would be helpful to understand further the model used within the client<->server interactions involving POST and/or Ajax operations. Specifically I am a bit confused how CRUD is securely achieved (ie: Read Only) where the only apparent associated privileges appear to be “all or nothing” using the View parameter in the DB Privacy settings.

Thank you in advance.

Respectfully
John G. Ellis AGMD, MBA-IT

FWIW here also are some posts that get into security, including an ebook.

Josh: Request for a Security Q&A Guide - Need help / App Organization - Bubble Forum

The Ultimate Guide to Bubble Security is out - 300 pages of privacy and security content - Tips - Bubble Forum

1 Like

DUDE: the only person who can write to the database is you, the Bubble programmer. This can only be done via the create and modify type actions. Literally that’s it. Plugins can’t do this on your behalf. The ability to write to the db is solely under your control.

If you write your workflows properly (e.g., any write action only happens when you explicitly allow it/whatever criteria are met) then you can achieve “read only” access for whatever.

End of story. There’s literally nothing else to know about this.

1 Like

Thank you. Since you are so emphatic about your position; I would appreciate it if you could point me to the technical reference you have based this insight on?

Cheers
John

Seriously, only YOU can write, modify, or delete anything in your database. And you have full control over related permissions. End story.

1 Like

I don’t dispute your assertion. However; I would like to read the information for understanding. I have worked in the IT industry long enough to always take an approach of scepticism regarding security. I suggest; this is always the most prudent approach. Therefore; I do like to form my own conclusions.

Obviously you have done your research and hence I thought it would be possible for you to pass on the information you had obtained that led you to such an absolute conclusion.

Regards,
John

1 Like

I think what’s going on here is you’re just procrastinating about finishing… or (more likely) starting your app. True?

Just go do something. We’ll wait for you.

1 Like

I respectfully suggest that unqualified assumptions are never a foundation of good judgement. I also believe that devolving a conversation from a purely technical nature to that of a personal nature is never a good idea if you wish to maintain respectful dialogue.

I wish you the best in all your future endeavours.
John

4 Likes

I do appreciate the curiosity about this topic. Let us know here if Bubble Support responds with anything meaningful. As no-coders there’s a level of trust that Bubble have done their security homework.

1 Like

Hello all;
Bubble did respond however it was a more generic technical response regarding RESTful architectures that did not really answer my specific question. Since that time I have determined that both AJAX transactions do use typical client side secure headers, and messaging techniques. However this does rely on the application layer.

My next step is to see if the transactions header can be intercepted at the application layer before the session layer, and if so can the transaction be modified. In short the goal is to attempt to change a JS/Ajax GET to a PATCH at the client browsers application prior to the TLS layer. As an alternative I will also attempt to create a PATCH call and just send it once I have trapped out the credentials.

Do I know if this will work… unequivocally I do not know, so no one should be concerned and I am not trying to be controversial. No personal attacks please.

However I do find it an interesting question to be explored over the winter.

1 Like